DEFENSE  LOGISTICS  ANALYSIS  OFFICE  FALLS  CHURCH  VA  F/S  15/5 

DOD  SUPPLY  SUPPORT  REQUEST  STUDY  (DODSSR).  VOLUME  II.  SYSTEMS  D— ETC(U) 
DEC  80 

NL 


FOREWORD 


By  Memorandum  dated  August  17,  1977,  the  Deputy  Assistant  Secre¬ 
tary  of  Defense  (Supply,  Maintenance  and  Services)  established 
a  Department  of  Defense  Study  to  conduct  a  comprehensive  review 
and  analysis  of  the  supply  support  request  (SSR)  systems  for 
generating,  transmitting,  processing  and  controlling  SSRs  In 
order  to  develop  systems  Improvements  to  promote  effective  supply 
support  of  DoD  equipments. 

The  Study  Included  a  review  of  SSR  policy  and  procedures,  the 
design  of  automated  systems  to  implement  the  procedures  and  an 
operational  implementation  review  of  the  effectiveness  of  SSR 
systems  design. 

This  Report  documents  the  study  approach  and  methodology  used  In 
the  pursuit  of  the  study  and  presents  observations,  analyses, 
findings,  conclusions  and  recommendations  with  supporting  re¬ 
search  and  rationale. 


T.  D.  BECK 
Director 
DODSSR  Study 
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PART  1 

SYSTEMS  DESIGN 


CHAPTER  I 


INTRODUCTION 


A.  GENERAL 


Systems  design  in  the  context  of  Part  1  of  this  Volume 
refers  to  the  design,  development,  programming  and  testing  of 
automated  data  processing  systems  to  implement  the  functional 
requirement  discussed  in  Volume  I.  The  interplay  between  these 
automated  data  processing  systems  and  manual  systems  and  proce¬ 
dures  is  described  under  the  operational  implementation  review 
in  Part  2  of  this  Volume.  The  design  process  consists  of  three 
phases.  The  first  phase  is  the  functional  requirements  statement 
for  requesting  and  obtaining  supply  support  as  discussed  in 
Volume  I.  The  second  phase  is  development  of  a  conceptual  system 
of  the  type  required  to  accomplish  the  functional  requirement. 

A  conceptual  system  of  this  type  is  presented  in  Volume  I.  A 
description  of  the  design  of  each  Component  automated  data  pro¬ 
cessing  system  developed  to  implement  the  functional  requirement 
in  terms  of  individual  design  concepts  is  the  final  phase.  This 
final  phase  is  discussed  by  Component  in  Part  1. 

The  description  for  each  Component  consists  of  a  discussion 
of  the  organizational  elements  responsible  for  the  automated 
systems  design  keyed  to  those  functional  areas  responsible  for 
preparing  functional  requirements,  system  specifications,  program 
specifications,  functional  users  manuals  and  training  procedures. 
A  general  SSR  Automated  System  Overview  is  presented  next  to 
show  the  automated  processes  involved  from  the  generation  of  SSR 
transactions  through  completion  of  each  SSR  item.  The  Component 
SSR  Subsystem/ App 1 ica t ion  is  discussed  last  and  provides  a 
detailed  description  of  processing  actions  on  a  program  module 
basis.  The  description  provided  for  each  Component  reflects  the 
latest  information  provided  to  the  study  team  during  the  course 
of  the  study.,.*  The  level  of  detail  of  the  description  of  each  SSR 
Subsystem/App’lication  varies  from  Component  to  Component  due  to 
the  variance  in  availability  of  systems  design  documentation. 

B.  DEFINITIONS 


Each  Chapter  within  Part  1  covers  the  system  design  of  a 
Component  by  subsystems,  applications  and  program  modules.  The 
disk  and  magnetic  tape  files  discussed  under  each  subsystem, 
application  and  program  module  fall  into  two  general  categories. 
The  files  discussed  under  Inputs  and  outputs  are  usually  temporary 
work  files,  while  those  discussed  in  the  files  sections  are  per¬ 
manent  operational  files  unless  otherwise  specified.  Also,  in  the 


bLotg-MOT  FltMLD 


3 


description  of  these  subsystems,  applications,  and  program  modules 
certain  generic  file  names  are  used  instead  of  the  file  names 
assigned  by  different  Components.  This  is  done  to  provide  a  con¬ 
sistent  basis  for  comparison.  The  two  predominant  generic  file 
names  used  include  local  TIR  file  and  SSR  Suspense  File.  The 
local  TIR  file  relates  to  an  activity  maintained  file  which  con¬ 
tains  cataloging  data  also  resident  in  the  DIDSTIR  file  at  DLSC 
in  addition  to  other  locally  used  data.  The  term  SSR  Suspense 
File  is  used  to  identify  the  major  automated  file  uses  for  stor¬ 
age,  access,  retrieval,  and  updating  of  SSR  transactions. 

There  are  certain  terms  used  repeatedly  in  Part  1  which  re¬ 
quire  definition  for  a  total  understanding  of  the  automated  sys¬ 
tems  design  of  each  Component.  The  terms  (system,  subsystem, 
application  and  program  module)  are  used  across  all  Components 
to  provide  a  consistent  base  for  analysis  and  comparison. 

1.  System.  A  system  as  used  in  this  Volume  for  the  purpose 
of  discussing  automated  systems  design,  consists  of  a  collection 
of  men,  machines  and  methods  organized  to  accomplish  a  set  of 
specific  data  processing  functions  using  a  series  of  logically 
related  procedures  directed  towards  the  accomplishment  of  one  or 
more  of  a  Component's  functional  responsibilities. 

2.  Subsystem .  A  subsystem  is  a  secondary  or  subordinate 
system  capable  of  operating  independently  of  other  subsystems 
and  generally  keyed  to  a  single  Component  functional  area;  e.g., 
provisioning. 

3.  Application.  An  application  consists  of  one  or  more 
program  modules  designed  to  perform  a  specific  major  event  or 
process  specific  types  of  transactions  within  a  single  func¬ 
tional  area;  e.g.,  performing  DLSC  screening  or  SSR  transaction 
processing . 

4.  Program  Module.  A  program  module  is  a  complete  set  of 
machine  instructions  and  routines  necessary  to  accomplish  one  or 
more  major  events  within  a  functional  area;  i.e.,  validation, 
file  maintenance. 


CHAPTER  II 


ARMY 


A .  INTRODUCTION 

The  Commodity  Command  Standard  System  (CCSS)  is  a  standard 
ADP  system  used  within  the  Army  at  the  Materiel  Readiness  Com¬ 
mands  (MRCs).  The  Automated  Logistics  Management  Systems  Activ¬ 
ity  (ALMSA)  is  the  central  systems  design  activity  responsible 
for  the  design,  programming  and  maintenance  of  individual  sub¬ 
systems,  applications  and  program  modules  within  CCSS.  Although 
this  standard  ADP  system  is  implemented  at  all  ARMY  MRCs,  each 
of  the  MRCs  maintain  a  separate  Autumated  Data  Processing  (ADP) 
staff  responsible  for  execution  of  CCSS  applications  and  respon¬ 
sible  for  designing,  programming  and  maintaining  local  MRC  pro¬ 
gram  modules.  Some  of  the  local  programs  interface  with  CCSS 
applications.  The  Supply  Support  Request  (SSR)  Application  in 
the  Army  was  developed  under  the  CCSS  umbrella  and  interfaces 
primarily  with  the  CCSS  Provisioning  Subsystem  and  the  CCSS 
Automated  Requirements  Computation  Application.  It  also  inter¬ 
faces  with  some  locally  developed  program  modules  discussed  in 
Part  2  of  this  Volume. 

B .  SYSTEMS  DESIGN  PROCESS 

The  SSR  processing  within  the  Army  falls  under  the  purview 
of  the  Directorate  of  Materiel  Management  in  Headquarters,  U.S. 
Army  Development  and  Readiness  Command  (USA  DARCOM) .  The  Direc¬ 
torate  for  Materiel  Management  has  assigned  responsibility  for 
overall  management  of  this  process  to  the  Catalog  Data  Activity 
( C D A ) .  C D A  is  a  field  activity  of  DARCOM  assigned  the  mission 
of  managing  Army-wide  participation  in  the  Federal  Catalog  System 
(FCS)  and  related  programs  including  the  DoD  Item  Management 
Coding  Program,  the  Defense  Integrated  Data  System  (DIDS),  and 
functional  guidance  for  the  cataloging  application  of  the  CCSS. 

C  DA  also  has  the  responsibility  of  reviewing  System  Change  Re¬ 
quests  (SCRs)  and  initiating  SCRs  for  specific  functions  related 
to  cataloging  -pplications  interfacing  with  CCSS.  With  the  added 
mission  of  managing  Army-wide  participation  in  the  DODSSR  Program 
came  the  responsibility  of  reviewing  and  initiating  SCRs  for  the 
SSR  process  which  interfaces  with  CCSS.  When  this  mission  was 
first  assigned,  the  SSR  process  was  totally  manual  and  did  not 
Impact  on  the  CCSS;  however,  with  the  implementation  of  the  new 
I  MM  manual  (Appendix  D,  Reference  9)  it  was  decided  to  automate 
the  SSR  process  as  a  separate  application  of  CCSS.  This  decision 
resulted  in  initiation  of  an  SCR  by  CDA  directing  ALMSA  to  develop 
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an  automated  system  for  SSR  processing  as  contained  in  the  new 
IMM  Manual  to  be  implemented  concurrently  with  the  implementa¬ 
tion  of  the  new  IMM  Manual  on  1  May  1978. 

ALMSA,  as  the  central  systems  design  activity  of  Headquarters 
DARCOM,  has  the  mission  of  developing  and  maintaining  standard 
application  programs  used  by  DARCOM  subordinate  commands;  to 
develop  automatic  data  processing  (ADP)  software  standards  for 
DARCOM  ADP  programming  and  to  serve  as  focal  point  for  standar¬ 
dization  of  data  codes  and  data  elements  and  advanced  ADP  tech¬ 
nology.  The  organizational  structure  of  ALMSA  is  shown  in  Figure 
1 1— 1 »  The  primary  mission  of  ALMSA  is  performed  by  the  Direc¬ 
torates  of  Materiel  Management,  Procurement  and  Finance,  and 
Technical  Data.  The  other  Directorates  are  involved  in  opera¬ 
tions  and  management  functions.  Each  of  these  three  Directorates 
consist  of  cwo  or  more  Divisions  as  shown  in  the  figure.  Gener¬ 
ally  each  division  consists  of  several  branches  or  teams.  There 
may  be  one  or  more  Design  and  Requirements  Branches  and  Program¬ 
ming  Branches;  however,  there  is  usually  a  single  Test  and  Vali¬ 
dation  Branch.  The  automation  of  the  SSR  process  was  assigned 
to  the  Logistics  Data  Division  within  the  Directorate  of  Tech¬ 
nical  Data. 

The  Design  and  Requirements  Branch  consists  of  both  func¬ 
tional  systems  analysts  and  computer  system  analysts.  This  is 
where  the  SCRs  are  received  and  processed.  This  branch  develops 
systems  specifications  for  use  by  the  Programming  Branches  in 
meeting  the  functional  requirements  set  forth  by  the  SCR.  In 
many  cases  a  Field  Functional  Coordinating  Group  ( FFCG)  is  set 
up  to  review  and  provide  explanation  of  the  functional  require¬ 
ments.  These  FFCGs  are  made  up  of  representatives  from  each  of 
the  DARCOM  MRCs  including  a  representative  from  the  appropriate 
Design  and  Requirements  Branch  at  ALMSA.  The  FFCG  is  chaired  by 
a  representative  from  Headquarters  DARCOM.  In  the  case  of  SSRs 
the  FFCG  was  attended  by  a  representative  from  CDA.  The  Design 
and  Requirements  Branch  is  also  responsible  for  developing  and 
maintaining  functional  systems  documentation  including  Functional 
Operating  Instructions;  determining  the  amount  of  training,  and 
the  number  of  functional  employees  to  be  trained,  and  aiding 
DARCOM  training  organizations  in  development  and  presentation  of 
training  materials;  assisting  User  Commands  during  system  imple¬ 
mentation  and  follow-on;  and  developing  and  reviewing  test  results 
for  new  applications  and  modifications  to  existing  systems. 

The  Programming  Branches  consist  of  computer  systems 
analysts  and  computer  programmers.  From  the  systems  specifica¬ 
tions  provided  by  the  Design  and  Requirements  Branch,  program 
production  design  specifications  are  prepared.  These  specifica¬ 
tions  are  used  to  perform  the  actual  programming  function.  This 
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Branch  is  responsible  for  providing  computer  programs  to  perform 
the  desired  functions  set  forth  in  the  system  specification, 
developing  and  maintaining  Computer  Operating  Instructions  for 
each  assigned  application,  participating  in  designing  test  data 
and  reviewing  test  results  and  assisting  system  users  in  imple¬ 
mentation  and  follow-on  problem  resolution. 

The  Test  and  Validation  Branch  performs  testing  of  all  appli¬ 
cations  assigned  to  the  division.  This  branch  insures  that  each 
new  application  or  revision  to  existing  applications  performs 
the  desired  operations;  reviews  the  test  results  with  the  FFCG, 
the  Programming  Branches,  and  the  Design  and  Requirements  Branch; 
and  coordinates  the  release  of  new  applications  or  revisions  to 
user  commands.  At  this  point  the  application  is  ready  for  re¬ 
lease  to  the  DARCOM  subordinate  commands  for  implementation. 

The  implementation  package  sent  to  each  of  the  subordinate 
commands  generally  consists  of  applicable  Commodity  Command 
Standard  System  Operating  Instructions  (CCSSOIs)  and  computer 
programs.  An  implementation  team  from  ALMSA  is  usually  assigned 
to  visit  each  subordinate  Command  to  aid  in  initially  setting  up 
new  applications  and  extensive  modification  of  existing  applica¬ 
tions.  After  installation  of  the  package  it  undergoes  testing 
at  each  subordinate  command  to  insure  that  it  interfaces  with 
current  CCSS  applications  and  local  Command  applications  already 
in  use.  The  testing  and  review  of  test  results  is  a  joint  effort 
between  the  Directorate  of  Management  Information  Systems  and 
the  applicable  Functional  Directorate  (Directorate  of  Materiel 
Management  for  the  SSR  process). 

Figure  II-2  illustrates  the  relationships  of  the  major  com¬ 
mand  elements  in  this  process.  As  illustrated  by  this  figure 
the  system  development  functional  guidance  comes  to  ALMSA  from 
the  Headquarters  DARCOM  Functional  Directorate  (in  the  case  of 
SSR  processing,  from  CDA  as  mission  assignee)  and  may  be  devel¬ 
oped  in  conjunction  with  the  FFCG.  ALMSA  technical  guidance 
comes  from  the  Directorate  for  Management  Information  Systems 
and  planning  guidance  including  requirement  prioritization  is 
established  by  the  Log  System  Review  Board.  Although  ALMSA 
receives  guidance  from  all  of  these  headquarters  level  elements, 
this  activity  reports  only  to  the  Directorate  of  Management 
Information  Systems  at  DARCOM.  ALMSA  in  turn  distributes  Stan¬ 
dard  Data  Processing  Systems  to  the  subordinate  Commands. 

Upon  review  of  the  functional  requirement  developed  by  CDA, 
ALMSA  proposed  a  two  phase  design  to  meet  the  requirement.  The 
primary  thrust  behind  the  two  phase  design  was  the  belief  that 
while  a  total  automated  system  to  process  both  outgoing  and 
incoming  SSR  transactions  could  not  be  developed  by  the  required 
implementation  date,  a  program  module  to  process  outgoing  SSR 


candidates  generated  by  the  Automated  Requirements  Computation 
Application  could  be  developed  for  implementation  concurrently 
with  the  IMM  Manual.  Under  this  proposal,  Phase  I  processing 
would  deal  only  with  outgoing  provisioning  SSR  transaction  genera¬ 
tion.  Phase  II  would  take  the  SSR  transactions  generated  in 
Phase  I;  add  to  them  manually  generated  SSR  transactions,  incoming 
SSR  transactions,  Line  Item  Advice  Cards  (LIACs)  and  inquiry  trans 
ations;  and  handle  all  validation  and  SSR  Suspense  File  processing 
This  proposal  was  accepted  and  the  Army  SSR  Application  was  then 
designed,  programmed  and  implemented  using  this  two  phase  concept. 
Phase  I  was  distributed  by  ALMSA  for  implementation  at  all  the 
MRCs  concurrently  in  May  1978.  Implementation  of  Phase  II  took 
place  concurrently  at  all  the  MRCs  in  April  1979. 

C.  SYSTEM  DOCUMENTATION 


The  initiating  document  is  generally  the  responsibility  of 
Headquarters  DARCOM  and  consists  of  an  SCR  setting  forth  func¬ 
tional  requirements.  These  functional  requirements  for  the  SSR 
process  took  the  form  of  the  latest  draft  IMM  Manual  under  cover 
of  the  SCR.  ALMSA  publishes  a  number  of  types  of  documents  as 
CCSSOIs.  The  three  most  predominant  types  include  Guidance 
Operating  Instructions,  Application  Operating  Instructions  and 
Functional  Operating  Instructions. 

1.  The  Guidance  Operating  Instructions  are  basically  a  guide 
to  a  particular  automated  file  and  contain  information  such  as 
file  contents,  file  organization  and  structure,  and  other  file 
characteristics.  The  guidance  operating  instructions  are  more 
commonly  used  by  functional  personnel  than  computer  operations 
personnel . 

2.  Functional  Operating  Instructions  are  intended  for  the 
use  of  functional  personnel  and  generally  give  a  brief  narrative 
of  operations  performed  in  each  progam  modules,  the  major  files 
used  in  the  application,  and  input/output  formats.  Also  given 
are  system  codes  generated  for  functional  use;  e.g.,  reject 
codes  . 

3.  Application  Operating  Instructions  are  basically  computer 
operating  instructions.  These  are  prepared  by  the  programming 
branch  and  provide  computer  operations  personnel  in  the  User  Com¬ 
mand  the  necessary  information  to  execute  the  application  job 
steps.  Other  CCSSOIs  are  also  produced  and  published,  but  on  an 
infrequent  basis.  The  actual  system  specifications  and  program 
production  design  specifications  are  generally  not  published  or 
disseminated  outside  of  ALMSA.  The  CCSSOIs  are  generally  pub¬ 
lished  and  disseminated  concurrently  with  the  release  of  the 
application  for  implementation. 
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The  DARCOM  subordinate  commands  generally  do  not  publish 
any  documentation  concerning  their  local  applications.  Func¬ 
tional  documentation  is  contained  in  Division  or  Directorate 
1  e  '• « 1  operating  instructions.  Applications  documentation  con¬ 
sists  of  generalized  run  flow  charts  and  computer  program  list¬ 
ings.  Additional  functional  documentation  at  the  Directorate  or 
Division  level  may  be  prepared  on  an  as  required  basis  to  supple 
ment  the  functional  operating  instructions  received  from  ALMSA 
for  CCSS  applications. 

D .  SYSTEM  OVERVIEW 

CCSS  was  established  to  standardize  the  wholesale  logistics 
operations  at  the  subordinate  commands  of  DARCOM.  This  includes 
standardization  of  ADP  programs,  data  elements  and  codes.  CCSS 
currently  contains  applications  in  the  areas  of  provisioning, 
cataloging,  supply  management,  procurement,  maintenance,  stock 
control,  in t e r no L i ona  1  logistics  and  financial  management.  The 
SSR  process  was  designed  as  a  single  application  within  CCSS. 

An  overview  of  this  application  along  with  interfacing  portions 
of  CCSS  is  shown  in  Figure  11—3.  As  shown  in  this  figure,  SSR 
candidates  are  generated  by  the  Automated  Requirements  Computa¬ 
tion  Application  tiy  combining  End  Item  data  with  ARCSIP  data 
passed  by  the  Provisioning  Subsystem.  SSRs  may  also  be  input  to 
the  SSR  application  directly  after  manual  generation.  Generally 
those  SSRs  input  directly  to  the  SSR  application  are  outgoing 
n o n p r o v i s i o n i n g  SSR  transactions,  incoming  SSR  transactions,  and 
Line  Item  Advice  Cards  (LIACs).  Each  of  the  major  processing 
blocks  (subsystem/application)  will  now  'e  discussed. 

1.  CCSS  Provisioning  Subsystem.  The  provisioning  subsystem 
consists  of  several  separate  applications  each  of  which  is 
designed  to  perform  specific  operations  on  provisioning  data. 
Since  we  are  not  specifically  concerned  with  how  the  provision¬ 
ing  process  takes  place,  but  more  how  the  provisioning  process 
leads  to  SSR  generation,  each  application  within  this  subsystem 
will  not  be  explained  separately.  The  single  exception  to  this 
is  the  CCSS  Part  Number  Screening  Application  which  is  part  of 
the  CCSS  Provisioning  Subsystem,  but  is  purposely  separated  out 
for  discussion  due  to  its  importance  in  the  SSR  process. 

a.  Inputs .  Input  to  the  CCSS  Provisioning  Subsystem  is 
initial  provisioning  documentation  from  the  contractor  In  the 
format  prescribed  by  MIL-STD  1552  (Appendix  D,  Reference  22). 
Other  inputs  Include  contractor  corrections,  additions  and  dele¬ 
tions;  functional  user  inquiries;  automated  inquiry  responses, 
and  functional  file  maintenance. 

b.  Files  .  The  major  files  used  in  the  Provisioning 
Subsystem  are  the  Local  TIR  File,  Provisioning  Cross  Reference 
(PXR)  File,  Provisioning  Master  Record  (PMR)  File,  and  the  Con¬ 
tract  History  File. 


(1)  Local  Total  Item  Record  (TIR)  File.  This  is 
the  National  Stock  Number  Master  Data  Record  File  in  the  ARMY 
and  is  the  major  file  used  in  day-to-day  operations  of  the  Com¬ 
mand-  It  contains  data  oriented  to  each  functional  element 
within  the  Command.  This  file  contains  most  or  all  of  the  data 
elements  located  in  the  Defense  Integrated  Data  System  Total 
Item  Record  (DIDSTIR)  plus  Army  peculiar  data  not  contained  in 
the  DIDSTIR.  Each  of  the  DARCOM  MRCs  has  a  Local  TIR  File  con¬ 
taining  items  for  which  it  has  Integrated  Materiel  Management 
(IMM)  responsibility  as  well  as  all  items  used  on  Army  End  Items 
assigned  for  management  to  that  Command.  This  disk  file  has 
indexed  sequential  organization  allowing  processing  in  a  batch 
mode  or  direct  access  mode  and  has  variable  length  record  struc¬ 
ture. 


(2)  Provisioning  Cross  Reference  (PXR)  File.  This 
file  allows  identification  of  all  uses  of  a  Part  Number  or  NSN 
contained  with!..  the  PMR  File.  This  disk  file  has  indexed 
sequential  organization  and  variable  length  record  structure. 

(3)  Provisioning  Master  Record  (PMR)  File.  This 
disk  file  acts  as  central  storage  for  data  used  in  the  provision¬ 
ing  of  an  end  item  and  allows  for  Identification  of  all  parts 
used  in  an  end  item.  It  has  indexed  sequential  organization 
based  on  the  Provisioning  Contract  Control  Number  (PCCN)  and 
variable  length  record  structure.  Records  remain  on  this  file 
until  the  provisioning  contract  is  completed;  at  that  time  they 
are  transferred  to  the  Contract  History  File. 

(4)  Contract  History  File.  This  disk  file  is  iden¬ 
tical  to  the  PMR  File  in  structure  and  content.  The  difference 
between  the  two  is  that  the  PMR  File  contains  only  active  con¬ 
tracts  while  this  file  contains  only  completed  contracts  and 
acts  as  a  history  of  the  provisioning  process  for  items  on  the 
file.  There  is  no  definite  retention  period  for  records  on  this 
file. 


c .  Processing 

The  initial  step  of  processing  is  to  edit  and  vali¬ 
date  the  provisioning  data  entered.  This  step  insures  that  all 
mandatory  data  elements  are  present  and  that  data  entered  is  in 
the  prescribed  format.  Input  found  to  be  invalid  is  printed  on 
the  Validation  Reject  Listing.  Valid  data  is  output  to  the  next 
processing  step  (PMR  file  maintenance).  A  file  of  Part  Numbers 
is  also  produced  from  the  validation  step;  this  file  serves  as 
input  to  the  CCSS  Part  Number  Screening  Application  discussed 
below. 
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The  second  step  of  provisioning  subsystem  processing 
performs  file  maintenance  against  the  PXR,  PMR,  and  Contract 
History  Files.  Records  are  initially  added,  changed  or  deleted 
during  this  processing  step.  The  primary  outputs  of  this  pro¬ 
cessing  step  are  a  reject  listing.  Provisioning  Technical  Docu¬ 
mentation  (PTD),  Transaction  History  Report,  transactions  to 
create  an  Automated  Selection  Worksheet,  transactions  to  update 
the  Local  TIR  File  and  transactions  to  be  passed  to  the  CCSS 
Automated  Requirements  Computation  Application. 

There  are  several  other  steps  in  the  provisioning 
subsystem  that  perform  actions  necessary  to  the  provisioning 
process  but  not  directly  impacting  on  the  generation  of  SSRs  and 
are  not  discussed  here  for  that  reason.  The  CCSS  Provisioning 
Subsystem  is  generally  executed  at  each  of  the  commands  on  a 
weekly  basis  in  a  single  job  stream  and  is  essentially  a  batch 
process  . 


d .  Outputs 

(1)  Validation  Reject  Listing.  This  listing  is 
generally  passed  to  the  contractor  for  error  correction. 

(2)  Part  Number  Screening  Items.  All  provisioning 
parts  submitted  without  an  NSN  are  passed  to  this  file  for  pro¬ 
cessing  in  the  CCSS  Part  Number  Screening  Application. 

(3)  File  Maintenance  Reject  Listing.  These  rejects 
are  generally  corrected  by  functional  personnel  and  relnput  to 
the  Provisioning  Subsystem. 

(A)  Provisioning  Technical  Documentation  (PTD) 
Transaction  History  Report.  This  report  provides  functional 
personnel  a  record  of  actions  taken  by  PCCN  in  that  processing 
cycle.  These  reports  indicate  to  functional  personnel  when 
enough  data  is  available  to  request  execution  of  the  CCSS  Auto¬ 
mated  Requirements  Computation  Application. 

(5)  Automated  Selection  Worksheets.  These  are  pre¬ 
printed  worksheets  on  which  all  available  data  for  each  item  is 
entered  upon  initial  entry  into  the  PMR  File.  This  worksheet  is 
the  basis  for  manual  provisioning  processing  resulting  in  PMR 
update  transactions  as  will  be  seen  in  Part  2  of  this  Volume. 

(6 )  Local  Total  Item  Record  (TIR)  File  Updates . 

This  disk  file  consists  of  required  data  to  build  records  on  the 
Local  TIR  File  for  items  new  to  the  command  and  update  records 
already  residing  on  the  file. 
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( 7 )  Automated  Requirements  Computation  System- 
Initial  Provisioning  (ARCSIP)  Data  Transactions.  This  magnetic 
tape  file  consists  of  transactions  containing  items  ready  for 
the  requirements  computation  process. 

2.  CCSS  Part  Number  Screening  Application.  This  applica¬ 
tion  takes  part  numbers  forwarded  by  the  CCSS  Provisioning 
Subsystem  and  determines  if  DLSC  screening  or  local  TIR  file 
screening  will  be  performed.  This  is  the  only  screening  ini¬ 
tiated  on  an  automated  basis  within  the  Army  SSR  process. 

a.  Inputs  .  Inputs  to  this  application  consist  of  part 
numbered  items  to  be  screened  that  are  generated  by  the  Provi¬ 
sioning  Subsystem  and  Replies  to  DLSC  screening  transactions 
previously  generated  by  this  application. 

b.  Files  .  There  are  two  files  used  in  this  application 
(Reference  Number  File  and  DLSC  Suspense  File). 

(1)  Reference  Number  (REFNO)  File.  This  is  a  cross- 
reference  file  which  serves  as  an  index  to  the  local  TIR  File. 
This  disk  file  contains  all  item  identification  numbers  used  by 
the  command  at  which  it  resides  and  includes  obsolete  stock  num¬ 
bers,  interchangeable  stock  numbers,  part  numbers,  and  future 
stock  numbers  as  well  as  current  prime  stock  numbers.  This  file 
is  sequenced  on  item  identification  number. 

(2)  DLSC  Suspense  File.  This  is  a  sequential 
magnetic  tape  file  containing  a  record  of  all  outstanding  DLSC 
screening  transactions. 

c .  Processing 


This  application  compares  each  part  number  item 
against  the  REFNO  File  to  determine  if  it  is  already  used  by  the 
Command  and  therefore  a  record  on  the  Local  TIR  File  exists.  If 
a  match  is  found  on  the  REFNO  File,  an  inquiry  transaction  is 
generated  to  be  processed  against  the  Local  TIR  File.  These 
transactions  are  processed  in  a  separate  application  which 
selects  data  from  the  local  TIR  file  and  produces  a  printout  of 
this  data  for  use  by  functional  personnel.  If  no  match  is  found, 
a  DLSC  screening  transaction  is  recorded  on  the  DLSC  Suspense 
File  and  forwarded  to  DLSC  for  screening  against  the  DIDSTIR 
File  . 


When  a  response  is  received  from  DLSC,  it  is  input 
to  this  application.  These  response  transactions  delete  the 
screening  transaction  from  the  DLSC  Suspense  File  and  are  printed 
as  Provisioning  Results  from  DLSC  for  use  by  functional  person¬ 
nel. 
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This  application  has  a  built-in  followup  procedure 
to  DLSC.  If  a  response  is  not  received  from  DLSC  in  15  days  the 
screening  transaction  is  regenerated  and  transmitted  to  DLSC. 

If  another  15  days  elapse  without  response,  the  screening  trans¬ 
action  is  transmitted  for  the  third  time.  When  a  response  is 
not  received  for  the  third  submittal,  the  transaction  if  cleared 
from  the  DLSC  Suspense  File  and  a  No  Response  notification  is 
forwarded  to  the  functional  user. 

d.  Out  puts.  Outputs  from  this  application  requiring 
further  automated  processing  include  Local  TIR  Inquiries  and  DLSC 
Screening  Inquiries.  Reports  generated  for  functional  use  in¬ 
clude:  List  of  DLSC  Submissions,  Local  TIR  Inquiry  Submissions, 

List  of  DLSC  Resubmittals,  and  Provisioning  Screening  Results 
from  1/LSC  for  manual  processing. 

(1)  Local  Total  Item  Record  (TIR)  Inquiries.  These 
transactions  will  be  matched  against  the  Local  TIR  File  for  a 
printout  of  current  data  on  the  original  part  numbe-  for  use  by 
functional  elements. 

(2)  DLSC  Screening  Inquiries.  These  transactions 
include  both  first  time  submittals  and  resubmittals  to  be  for¬ 
warded  to  DLSC  via  AUTODIN  for  screening  against  the  DIDSTIR  File. 

(3)  List  of  DLSC  Submissions.  This  is  a  list  of 
first  time  submittals  for  screening  against  the  DIDSTIR  File. 

( 4 )  Local  Total  Item  Record  (TIR)  Inquiry  Submls- 
sions.  This  is  a  list  of  transactions  for  screening  against  the 
Local  TIR  File. 

(5)  List  of  DLSC  Resubmittals .  This  is  a  list  of 
transactions  for  which  a  reply  from  DLSC  was  overdue  and  a  re- 
submittal  of  the  transaction  was  made. 

(6)  Provisioning  Results  from  DLSC.  This  is  a 
printout  of  the  results  of  the  screening  against  the  DIDSTIR 
File  . 

3 .  CCSS  End  Item  Parameter  (EIP)  File  Update  Application. 

This  application  is  an  update  of  the  End  Item  Parameter  File 
which  is  necessary  before  the  CCSS  Automated  Requirements  Com¬ 
putation  Application  may  be  executed. 

a.  Inputs  .  Input  consists  of  update  transactions  to 
add,  change,  delete  or  print  end  item  parameter  data.  These 
transactions  are  generated  manually  by  the  functional  user. 

b.  Files .  The  only  file  used  is  the  End  Item  Parameter 
(EIP)  File.  This  disk  file  contains  end  item  program  data  used 
in  the  requirements  computation  and  SSR  generation  processes. 
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c.  Processing.  Processing  consists  of  validation  of 
update  transactions,  updating  the  EIP  File  with  valid  transac¬ 
tions  and  rejecting  invalid  transactions. 

d.  Output.  A  reject  list  and  the  total  EIP  File  is 
printed  for  functional  use. 

4 .  CCSS  Automated  Requirements  Computation  Application. 

This  application  computes  retail  and  wholesale  gross  require¬ 
ments  to  support  an  end  item  through  the  program  forecast  period 
for  locally  managed  items  and  for  the  first  year  of  deployment 
for  nonlocally  managed  items. 

a.  Inputs.  The  two  basic  inputs  to  this  application 
are  ARCSIP  Da t a  Transactions  from  the  Provisioning  Subsystem  and 
ARCSIP  Request  Cards. 

( 1 )  Automated  Requirements  Computation  System- 
Initial  Provisioning  (ARCSIP)  Data  Transactions. 

( 2 )  Automated  Requirements  Computation  System- 
Initial  Provisioning  (ARCSIP)  Request  Cards.  These  cards  are 
prepared  manually  by  functional  personnel.  A  single  request 
card  may  execute  the  application  for  all  items,  for  all  items 
not  previously  computed,  for  re computat ion  of  items  previously 
computed,  or  for  a  single  item  within  an  end  item.  Cards  con¬ 
taining  manually  computed  quantities  may  also  be  entered  to 
effect  updating  of  the  PMR  and  Local  TIR  Files. 

b .  Files 

( 1 )  End  Item  Parameter  (EIP)  File. 

(2)  Provisioning  Master  Record  (PMR)  File. 

(3)  Materiel  Management  Decision  ( MMD )  File.  This 
disk  file  Is  used  to  provide  rules  for  computing  quantities  of 
Source  Code  "PB"  (insurance  items). 

c .  Processing 


This  application  is  executed  on  an  as  required  basis 
when  initiated  by  one  or  more  ARCSIP  request  transactions.  These 
transactions  are  first  validated  with  invalid  transactions  being 
dropped  from  further  processing  and  eventually  listed.  Valid 
transactions  pass  to  the  actual  computation  process  where  required 
data  is  extracted  from  the  PMR  File,  EIP  File,  and,  for  insurance 
type  items,  the  MMD  File.  If  required  data  is  missing,  require¬ 
ments  are  not  computed.  When  PMR  data  is  missing  the  Incomplete 
PMR  Data  for  ARCSIP  List  is  generated.  When  EIP  data  Is  missing, 
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it  is  reflected  in  the  ARCSIP  Computation  Statistics  Report. 
Computations  are  performed  for  an  item  when  all  required  data  is 
present  and  the  item  contains  a  Source  Code  of  PA,  PB,  PC,  PD  or 
PG  and  a  Maintenance  Code  of  C,  D,  F,  H,  L  or  0.  These  Source 
Codes  and  Maintenance  Codes  are  assigned  from  the  Joint  Regula¬ 
tion  on  SM&R  Codes  (Appendix  D,  Reference  20).  When  an  item 
meets  these  criteria;  is  managed  by  another  Army  activity,  or 
DLA/GSA;  and  a  retail  or  wholesale  quantity  is  computed,  an  SSR 
candidate  transaction  will  be  generated.  Several  other  output 
transaction  files  are  produced  for  further  processing  including 
the  AUTODIN  Transaction  File,  ARCSIP  PMR  Transaction  File,  and 
Local  TIR  Transaction  File. 

It  was  pointed  out  above  that  an  ARCSIP  c<  rd  may 
request  a  re compu t a t i on  for  items  previously  computed  either 
manually  or  by  this  application.  When  recomputation  results  in 
a  change  to  the  quantities  previously  computed,  an  SSR  candidate 
will  be  generated  containing  a  change  code  and  the  amount  of 
increase  or  decrease  in  quantities.  From  these  SSR  candidates, 
SSR  change  transactions  may  be  generated  by  the  SSR  application. 

d .  Outputs 

(1)  Reject  Listing.  Listing  of  invalid  request 
transactions  . 

( 2 )  Incomplete  Provisioning  Master  Record  (PMR) 

Data  for  Automated  Requirements  Computation  System-Initial 
Provisioning  (ARCSIP)  List.  Listing  of  all  items  for  which  com¬ 
putation  was  requested,  but  required  data  was  missing  from  the 
PMR  File. 


( 3 )  Automated  Requirements  Computation  System- 
Initial  Provisioning  (ARCSIP)  Computation  Statistics  Report. 

This  report  gives  various  counts  resulting  from  the  computation 
process,  e.g.,  number  of  SSR  candidates  produced. 

( 4 )  Automated  Digital  Network  (AUTODIN)  Transaction 
File.  These  are  transactions  to  be  forwarded  to  other  Army 
activities.  They  contain  data  to  update  the  requirements  por¬ 
tion  of  the  Local  TIR  File  at  these  other  Array  activities. 

These  transactions  are  produced  when  an  item  is  managed  by  an 
Army  activity  other  than  the  Provisioning  Activity. 

( 5 )  Automated  Requirements  Computation  System- 
Initial  Provisioning  (ARCSIP)  Provisioning  Master  Record  (PMR) 
Transaction  File.  These  transactions  are  input  to  the  CCSS 
Provisioning  Subsystem  to  add  the  computed  quantities  to  the  PMR 
File  for  each  item  that  completed  the  computation  process. 
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( 6 )  Local  Total  Item  Record  (TIR)  Transaction  File. 
These  are  update  transactions  to  add  the  computed  quantities  for 
each  Item  to  the  requirements  portion  of  the  local  TIR  File. 

(7)  SSR  Candidate  Transaction  File.  These  are 
transactions  containing  both  end  item  and  repair  part  data  from 
which  SSRs  to  other  actl/ities  -  Army,  other  Services,  DLA  and 
GSA  activities  -  are  to  be  produced  in  the  SSR  Application. 

(8)  Initial  Requirements  Studies.  These  are  pro¬ 
duced  for  locally  managed  repair  parts  or  new  items  to  be  retained 
for  management  and  are  used  by  functional  elements  for  manual 
review  of  current  stockage  and  initiation  of  procurement  actions 
to  support  initial  requirements. 

5.  CCSS  SSR  Application.  SSR  processing  within  the  Army  is 
a  combination  of  manual  and  automated  actions.  The  generation 
of  outgoing  provisioning  SSR  transactions,  the  generation  of 
advice  transactions  containing  ATC  "YE"  (unconditional  support 
accepted),  the  generation  of  followup  transactions,  and  under 
certain  conditions,  the  generation  of  followup  response  transac¬ 
tions  are  automated  under  this  application.  A  general  discussion 
1 8  presented  here  to  complete  the  system  overview  which  is  fol¬ 
lowed  by  a  detailed  presentation  of  the  SSR  application. 

a.  Inputs .  Inputs  to  this  application  consist  of  SSR 
Candidate  Transactions,  manually  generated  SSR  transactions  and 
SSR  Suspense  file  inquiries,  incoming  SSR  transactions  and  in¬ 
coming  LIACs . 

(1)  SSR  Candidate  Transactions.  These  are  transac¬ 
tions  generated  for  provisioning  items  by  the  Automated  Require¬ 
ments  Computation  Application. 

(2)  Manual  SSR  Transactions  and  Inquiries.  These 
transactions  Include  manually  generated  SSR  transactions  (gener¬ 
ally  nonproviaioning)  and  functional  user  inquiries  to  the  SSR 
Suspense  File.  Also  included  are  outgoing  LIACs. 

(3)  Incoming  SSR  Transactions.  These  are  transac¬ 
tions  submitted  by  other  activities  to  an  Army  activity  as  the 
WIMM  for  these  items. 

(A )  Incoming  Line  Item  Advice  Card  (LIAC)  Transac¬ 
tions  .  These  are  transactions  submitted  via  AUTODIN  from  IMMs 
which  provide  advice  on  SSR  transactions  sent  by  the  Army  activ¬ 
ity  as  a  SICC.  This  also  includes  followup  transactions  on 
incoming  SSR  transactions  previously  submitted  to  this  activity 
as  a  WIMM. 
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b.  Files  .  The  files  accessed  by  this  application  include 
the  Local  TIR  File,  Reference  Number  File,  Federal  Supply  Classi¬ 
fication  File,  Major  Organizational  Entity  Rules  File  and  SSR 
Suspense  File . 

( 1 )  Local  Total  Item  Record  (TIR)  File. 

(2)  Reference  Number  (REFNO)  File. 

( 3 )  Federal  Supply  Classification  Table  (FSC)  File. 
This  is  a  disk  cross-reference  file  which  relates  all  FSC  classes 
to  the  appropriate  class  manager  or  activity.  This  file  may  be 
used  to  determine  the  applicability  of  integrated  materiel  man¬ 
agement,  item  management  coding  or  single  submitter  procedures 

to  an  FSC  or  simply  to  determine  the  validity  of  an  FSC. 

( 4 )  Major  Organizational  Entity  (MOE)  Rules  File. 

This  is  a  disk  cross-reference file that relates service /agency 
MOE  Rule  numbers  to  corresponding  activity  code/item  status  code 
combinations.  The  MOE  Rules  establish  FSC  assignments,  supply 
management  relationships  and  control  of  descriptive  and  supply 
data  dissemination. 

(5)  SSR  Suspense  File.  This  disk  file  contains  a 
record  of  incoming  and  outgoing  SSR  Transactions.  It  is  gener¬ 
ally  organized  based  on  PCC  package  and  acts  as  an  active, 
suspense  and  history  file. 

c.  Processing.  SSR  candidates  generated  by  the  CCSS 
Automated  Requirements  Computation  Application  are  examined  for 
complete  data  and,  if  complete,  are  converted  to  the  SSR  formats 
prescribed  by  the  I  MM  Manual.  If  data  is  incomplete  or  an  error 
condition  is  encountered,  the  candidate  is  rejected  and  no  SSR 
transaction  is  prepared.  These  SSR  transactions  are  then  com¬ 
bined  with  the  additional  Inputs  shown  on  Figure  II-3.  These 
additional  input  transactions  are  then  validated  and,  based  on 
the  validation,  a  reject  code  may  be  assigned.  All  valid  trans¬ 
actions  and  some  invalid  transactions  are  posted  to  the  SSR 
Suspense  File  and  output  transactions  and  listings  are  generated. 
An  additional  processing  step  to  this  application  includes  a 
purge  of  the  SSR  Suspense  File  and  generation  of  followup  trans¬ 
actions  for  SSR  advices  overdue. 


d .  Outputs 

(1)  SSR  Candidates  Rejected.  These  are  SSR  trans¬ 
actions  from  the  Automated  Requirements  Computation  Application 
that  were  not  converted  to  SSR  transactions.  These  transactions 
are  printed  on  a  reject  list  and  returned  to  the  functional  area 
for  further  processing. 


( 2 )  Local  Total  Item  Record  (TIR)  Inquiries  .  Ihese 
are  inquiries  to  the  Local  TIR  File  to  print  selected  data  for 
manual  advice  determination  on  incoming  SSR  transactions. 

(3)  SSR  Cards.  This  includes  outgoing  and  incoming 
SSR  cards  and  LIACs. 

(4)  Line  Item  Advice  Cards  (LIACs).  These  are 
advice  cards,  followups,  and  responses  to  followups  to  be  trans¬ 
mitted  via  AUTODIN. 

(5)  SSR  Listings.  These  are  listings  of  SSR  trans¬ 
actions  processed  during  the  cycle  for  functional  use  including 
SSR  Suspense  Inquiry  Results,  Outgoing  SSR  Reject  List,  Incoming 
SSR  Reject  List,  Outgoing  SSR  List  (valid  only),  and  Incoming 
SSR  List  (valid  only). 

(6)  Reject  Reentry  Cards.  These  cards  are  produced 
for  outgoing  SSRs  failing  validation.  They  are  for  functional 
use  in  making  corrections. 

E .  DETAIL  SSR  APPLICATION  DESCRIPTION 

This  application  consists  of  five  program  modules  -  SSR  con¬ 
verter,  SSR  Edit  and  Validation,  SSR  File  Maintenance,  SSR  Out¬ 
put  Generator,  and  SSR  File  Surveillance.  Each  of  these  program 
modules  is  explained  in  terms  of  their  inputs,  files,  processing 
and  outputs.  Figure  II-4  is  a  detailed  breakdown  of  the  SSR 
Application  block  in  Figure  I  I  —  3  •  This  chart  is  divided  into 
two  sections  -  Phase  I  and  Phase  II.  The  SSR  application  was 
divided  into  these  two  phases  during  the  design  process  and  was 
also  implemented  in  this  manner.  Under  Phase  I  implementation, 
SSR  transactions  created  by  the  SSR  Converter  Program  Module 
were  written  on  a  magnetic  tape.  Upon  implementation  of  Phase 
II  the  magnetic  tape  becomes  a  temporary  disk  file. 

The  SSR  Converter  operates  as  a  sequential  process  in  a 
batch  processing  mode.  With  implementation  of  Phase  I  and  Phase 
II,  the  SSR  Converter  would  be  scheduled  as  a  single  job  step 
with  the  SSR  Edit  and  Validation,  SSR  File  Maintenance  and  SSR 
Output  Generator  Program  Modules  scheduled  together  in  a  single 
job  stream  and  executed  on  an  as  required  basis.  The  ALMSA 
recommended  frequency  is  twice  weekly.  The  SSR  File  Surveillance 
Program  Module  is  a  sequential  process  scheduled  separately  from 
the  other  program  modules  with  ALMSA  recommended  frequency  of 
once  per  month . 
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SSR  Converter 


a.  Inputs  ■  The  single  input  to  this  raodu’e  is  the  SSR 
candidate  transactions  from  the  CCSS  Automated  Requirements  Com¬ 
putation  Application.  These  candidates  consist  of  interservice 
and  intra-Army  transactions  for  consumable  and  reparable  items. 
Each  transaction  is  a  combination  of  Program  and  Line  Item  Dats . 
SSR  transaction  data  contained  in  these  candidates  are: 


*  Provisioning  Control  Code 

*  End  Item  NSN 

*  End  Item  Name 

*  Date  NSN  Required 

*  Date  Repair  Parts  Required 

*  End  Item  Delivery  Code 

*  Army  Weapon  Systems  Code 

*  Production  Lead  Time 

*  Uni t  of  Issue 

*  Unit  of  Issue  Price 

*  Procurement  Method  Code 

*  Source  Code 

*  End  Item  Quantity 

*  Percent  of  End  Items  East 

*  Shelf  Life  Code 

*  Item  Serial  Number 

*  Repair  Part  NSN  or  MC N 

*  Repair  Part  FSCM 

*  Manufacturers  Part  Number 

*  Type  Change  Code  (C  or  D  only) 

*  Replenishment  Quantity 

*  Retail  Quantity 

*  RIC  Support  Item  Manager 

*  Demilitarization  Code 

*  Reference  Number  Format  Code 

*  Quantity  per  End  Item 

*  Special  Material  Content  Code 

Data  not  contained  in  the  candidate  transactions,  but  required 
for  SSR  generation  is  provided  by  the  files  accessed,  or  the 
program  module  itself. 

b.  Files .  The  major  files  accessed  are: 

(  1  .  Federal  Supply  Classification  (FSC)  Table  File 

(2)  Major  Organizational  Entity  (MOE)  Rule  File. 

( 3 )  Reference  Number  (REFNO)  File. 


( 4 )  Local  Total  Item  Record  (TIR)  File 
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c .  Processing 

The  SSR  Converter  looks  at  each  transaction  to  deter¬ 
mine  if  it  is  a  consumable  or  a  reparable  item.  If  reparable,  it 
is  rejected  for  manual  action  and  eliminated  from  further  auto¬ 
mated  processing.  Next  the  destination  activity  code  is  deter¬ 
mined  from  the  FSC  File  and  the  Local  TIR  File  after  which  the 
candidate  is  examined  for  complete  data.  If  the  candidate  is 
incomplete,  it  is  rejected  for  manual  action.  The  SSR  candidates 
are  then  validated  for  proper  control  data  and  duplicate  trans¬ 
actions.  For  valid  candidates,  SSR  transactions  are  generated 
from  the  candidate  data,  data  extracted  from  the  Local  TIR  File, 
REFNO  File  and  MOE  Rule  File;  and  data  assigned  by  the  program 
module.  The  Type  Change  Code  appearing  in  the  candidate  applies 
to  the  Line  Item  Supply  Support  Request  (LISSR)  transaction  only 
and  therefore  must  be  converted  for  use  in  the  Program  Data  Supply 
Support  Request  (PDSSR)  transaction.  Data  extracted  from  the 
files  mentioned  include  MOE  Rule  Data,  Reference  Number  Category 
Code  (RNCC),  Reference  Number  Variation  Code  (RNVC),  Document 
Availability  Code  (DAC),  Technical  Data  Justification  Code  (TDJC), 
Reference  Number  Justification  Code  (RNJC),  and  all  Manufacturers 
Part  Numbers  and  FSCMs  related  to  the  repair  part.  Data  elements 
supplied  by  the  program  module  are  Activity  Code  From,  Date  of 
Request  (DOR  set  equal  to  process  date  plus  15  days).  Number  of 
SSRs  Enclosed,  Item  Management  Code  (IMC),  Acquisition  Advice 
Code  (AAC),  Interchangeability  Code,  Date  Technical  Data  to  be 
Supplied;  and  Document  Identifier  Code  (D1C). 

A  LISSR  transaction  is  created  for  an  NSN  item,  a 
PSCN  item,  or  a  Part  Number  item  from  each  complete  SSR  can¬ 
didate.  An  Item  Name  Card  transaction  will  be  created  for  each 
Part  Number  LISSR  transaction.  For  all  LISSR  transactions 
created,  additional  Reference  Number  transactions  will  be 
created  for  all  related  part  numbers  in  the  REFNO  File.  Addi¬ 
tional  user  transactions  are  not  mechanically  generated.  A 
single  PDSSR  transaction  is  generated  for  each  group  of  LISSR 
transactions  with  identical  control  information  -  Destination 
Activity  Code  (ACT),  Provisioning  Control  Code  (PCC),  and  DOR. 

A  "C”  is  appended  to  each  SSR  transaction  forwarded  to  Phase  II; 
these  transactions  then  bypass  some  of  the  validation  done  in 
the  Phase  II  program  modules. 

d .  Outputs 


(1)  SSR  Transactions  -  These  are  valid  SSR  transac¬ 
tions  passed  to  Phase  II  for  further  processing. 

( 2 )  SSR  Candidates  Rejected  -  These  transactions 
are  eventually  printed  out  and  forwarded  to  the  functional  area 
for  manual  processing. 
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2. 


SSR  Edit  and  Validation 


a.  Inputs  .  Inputs  to  this  program  module  include  out¬ 
going  SSR  packages  from  the  SSR  converter  module,  manual  SSR 
input,  and  incoming  LIAC  transactions  submitted  via  AUTODIN. 

( 1 )  Outgoing  Provisioning  SSR  transact  ion  packages 
are  contained  in  the  SSR  transaction  file. 

(2)  Manual  SSR  input  includes  outgoing  provisioning 
and  nonprovisioning  SSR  transaction  packages,  incoming  SSR  trans¬ 
action  packages,  LIAC  transactions  (outgoing  and  incoming),  SSR 
Suspense  File  inquiries  and  Reject  Reentry  Cards. 

(3)  Incoming  Line  Item  Advice  Card  Transactions 
(LIAC)  transmitted  over  AUTODIN  are  accumulated  on  an  interim 
tape  file  upon  receipt  for  processing  in  the  next  cycle. 

b.  Files .  The  files  accessed  by  this  program  module 

include : 

( 1 )  Reference  Number  (REFNO)  File . 

(2)  Local  Total  Item  Record  (TIR)  File. 

( 3 )  SSR  Suspense  File 

This  is  the  major  ile  relating  to  SSR  processing 
and  thus  is  discussed  in  much  greater  etail  than  other  files 
discussed  in  this  paragraph.  This  file  acts  as  an  operational, 
suspense  and  history  file  of  SSR  transactions.  The  SSR  Suspense 
File  is  a  permanent  disk  file  with  indexed  sequential  organiza¬ 
tion,  each  record  is  of  varying  length  and  interna1  structure. 

The  first  record  contains  indexing  information  which  provides  an 
interface  between  individual  SSR  records  and  processing  programs. 
This  index  record  is  followed  by  individual  SSR  records  made  up 
of  SSR  transaction  data  for  all  transactions  entering  the  SSR 
suspense  file  with  matching  PCC. 

Each  SSR  record  begins  with  a  data  header  por¬ 
tion  containing  basic  identification  data,  including  the  PCC 
which  is  the  controlling  element  for  sequencing  SSR  records  on 
the  file.  Following  this  data  header  are  all  unique  PDSSR  trans¬ 
actions  with  a  matching  PCC.  These  PDSSR  transactions  are  se¬ 
quenced  on  PCC,  ACT,  ACF,  and  DOR.  After  the  PDSSR  transactions, 
a  series  of  LISSR  headers  may  be  present.  These  LISSR  headers 
are  Summary  records  of  LISSR  transactions  in  the  SSR  record 
which  have  been  completed.  They  contain  only  basic  control  in¬ 
formation  and  the  completion  date.  They  are  sequenced  on  PCC, 

ACT,  ACF,  DOR,  ISN  and  NSN .  Behind  these  ISN  headers,  LISSR 


transactions  containing  an  NSN  or  PSCN  appear.  These  LISSR 
transactions  are  sequenced  the  same  as  the  ISN  headers.  Follow¬ 
ing  these  LISSR  transactions  are  LISSR  transactions  containing 
part  numbers.  Although  these  transactions  are  submitted  as  two 
cards,  they  are  combined  into  a  single  transaction  in  the  SSR 
record  and  are  sequenced  on  PCC,  ACT,  ACF,  DOR,  ISN.  Next  any 
Item  Name  transactions  matching  a  LISSR  will  appear.  These 
transactions  are  sequenced  on  PCC,  ACT,  ACF,  DOR,  and  ISN.  Addi¬ 
tional  reference  transactions  matching  a  LISSR  are  next  in  the 
SSR  record  and  are  recorded  in  PCC,  ACT,  ACF,  DOR,  ISN,  Part 
Number  sequence.  Additional  User  transactions  matching  a  LISSR 
transactions  follow  the  Additional  Reference  transactions  in 
PCC,  ACT,  ACF,  DOR,  ISN,  and  Additional  User  sequence.  Behind 
these  transactions,  LIAC  transactions  with  a  matching  PCC  are 
recorded.  Advice  and  followup  response  transactions  are  recorded 
first  followed  by  offer  reply  and  followup  transactions.  Only 
the  latest  advice  transaction  or  followup  response  transaction 
matching  on  PCC,  ACT,  ACF,  DOR,  and  ISN  is  present  on  the  file. 
When  an  additional  transaction  of  this  type  is  received  and  re¬ 
corded  on  the  file  it  replaces  the  previously  recorded  transac¬ 
tion.  The  same  situation  exists  for  offer  advice  and  followup 
transactions.  This  file  structure  is  illustrated  below: 

SSR  Index  Record 

SSR  Record  //I 

SSR  Header 

PDSSR  Data 

PDSSR  Data 

ISN  Header 

ISN  Header 

LISSR  w/NSN  Data 

LISSR  w/PSCN  Data 

LISSR  w/NSN  Data 

LISSR  w/Part  Number  Data 

Item  Name  Transaction  Data 

Item  Name  Transaction  Data 

Additional  Reference  Transaction  Data 

Additional  Reference  Transaction  Data 

Additional  Reference  Transaction  Data 

Additional  User  Transaction  Data 

Followup  Response  Transaction  Data 

Advice  Transaction  Data 

Advice  Transaction  Data 

Followup  Response  Transaction  Data 

Followup  Transaction  Data 

Offer  Reply  Transaction  Data 

Offer  Reply  Transaction  Data 

Followup  Transaction  Data 

SSR  Record  f?  2 

e  t  c  . 
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Transactions  recorded  on  this  file  do  not  appear 
as  a  simple  card  image.  The  SSR  Header  contains  basic  PCC  con¬ 
trol  data  and  a  completion  date.  ISN  headers  are  similar  in  that 
they  contain  basic  ISN  control  information  and  a  completion  date. 
The  SSR  transactions  recorded  begin  with  basic  file  control  data 
followed  by  data  elements  keyed  to  transaction  type  and  ending 
with  space  for  a  single  reject  code  and  process  date.  This  re¬ 
cording  is  illustrated  below  for  a  LISSR  containing  an  NSN  or 
PSCN  and  an  advice  transaction. 

*  LISSR  containing  an  NSN  or  PSCN 

System  Generated  File  Control  Data 

DIC 

ACT 

TCC 

NSN 

MOE  Rule 

Retai  1  Quant i t  y 

IMC 

ACC 

Replenishment  Quantity 

Quantity  per  End  Item 

Source  Code 

ISN 

DOR 

Unit  of  Issue 
SMCC 

Demilitarization  Code 
PCC 

Authorized  II  Data  Receiver  Code 
Authorized  II  Data  Collaborator  Code 
PMC 

Interchangeability  Code 
ACF 

Material  Management  Aggregation  Code 

Shelf -Life  Code 

Production  Leadtime 

Unit  Price 

Reject  Code 

Process  Date 

Total  Length  -  87  positions. 

*  Advice  Transaction 

System  Generated  File  Control  Data 

DIC 

ACT 

TCC 
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NSN/PSCN/Part  Number 

l  SN 

DOR 

DO. 

PCC 
FSCM 
ATC 
AC  F 

F SC/ Support  Date 
Reject  Code 
Process  Date 

Total  Length  -  78  positions, 
c .  Processing 


Generally  processing  in  this  module  consists  of  vali¬ 
dating  SSR  transactions.  This  validation  is  a  four-step  process, 
including  validation  of  (1)  control  data  elements,  (2)  stock 
numbers,  (3)  detail  data  elements,  and  (4)  SSR  packages.  Actual 
processing  begins  with  a  sort  of  all  input  transactions  into  the 
following  sequence: 


(1) 

PCC 

(2) 

Activity  Code 

To  (ACT) 

(3) 

Activity  Code 

From  (ACF ) 

(A) 

DOR 

(5) 

ISN 

(6) 

DIC 

(7) 

Card  Number 

The  transactions  are  then  validated  in  the  sequence  outlined  by 
the  four  step  process  and,  if  invalid,  are  assigned  an  Army 
reject  code.  As  part  of  the  validation,  a  check  is  made  for 
duplicate  input  transactions.  If  duplicates  are  found,  the  first 
continues  processing  and  the  remainder  become  fatal  errors.  In 
addition  each  transaction  is  checked  against  the  SSR  Suspense 
File  to  determine  if  a  transaction  with  identical  control  infor¬ 
mation  already  exists  on  the  file;  when  this  occurs  the  transac¬ 
tion  on  the  file  is  purged  and  the  new  record  is  passed  to  the 
next  program  module.  Also  each  LIAC  and  Reject  Reentry  Card 
must  have  an  SSR  transaction  with  matching  control  elements  on 
the  SSR  Suspense  File.  If  a  matching  transaction  is  not  found, 
a  fatal  error  condition  results. 
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After  validation,  three  types  of  transactions  remain  - 
transactions  with  fatal  rejects,  valid  transactions,  and  trans¬ 
actions  with  nonfatal  rejects.  Fatal  rejects  include  duplicate 
transactions;  LIACs  and  Reject  Reentry  Cards  not  matching  an  SSR 
Suspense  File  Record;  or  an  invalid  condition  in  one  of  the 
following  data  elements: 

(1)  Activity  Code  To 

(2)  Part  Number /FSCM 

(3)  PSCN 

(4)  NSN 

(5)  DIC 

(6)  PCC 

(7)  ISN 

(8)  Type  Change  Code 

(9)  Activity  Code  From 

All  other  types  of  rejects  are  nonfatal.  As  shown  in  Volume  I, 
Chapter  III,  validation  rejects  was  one  of  the  largest  problems 
reported  and  a  detailed  analysis  is  required  to  thoroughly  cover 
this  processing  event.  As  a  result,  detailed  discussion  of  vali¬ 
dation  criteria  is  done  jointly  in  Volume  III,  Chapter  III,  rather 
than  on  a  separate  Se r vice / Ac t i vi t y  basis. 

The  processes  described  apply  to  all  inputs  except  out¬ 
going  SSRs  from  the  SSR  Converter  Program  Module,  which  are  only 
minimally  validated  here  and  SSR  Suspense  File  Inquiries  which 
are  not  validated.  Outgoing  SSR  transactions  from  the  Converter 
Program  Module  are  generally  not  validated  in  Phase  II  processing 
because  the  data  elements  making  up  the  SSR  transaction  were 
validate  before  entering  the  automated  files  from  which  the  SSR 
transactions  are  eventually  created.  No  action  is  taken  on 
Suspense  File  Inquiries  in  this  program  module. 

d.  Outputs .  The  single  output  from  this  program  module 
is  the  combined  SSR  transactions  file  passed  to  the  next  program 
module.  These  transactions  consist  of  all  the  input  transactions 
mentioned  above.  No  transactions  are  dropped  by  this  program 
module  and  none  have  been  added. 

3.  SSR  File  Maintenance 


a.  Inputs  .  All  types  of  SSR  transactions  from  the  SSR 
Edit  and  Validation  Program  Module  including: 


(1)  Outgoing  SSR  Transactions 

(2)  Incoming  SSR  Transactions 

(3)  Outgoing  Line  Item  Advice  Card  (LIAC)  Transac¬ 
tions 

(4)  Incoming  Advice,  Offer  Reply  and  Followup 
Response  Transactions 

(5)  Incoming  Followup  Transactions 

(6)  Reject  Reentry  Cards 

(7)  SSR  Suspense  File  Inquiries 

b.  Files .  Files  accessed  by  this  program  module  have 
all  been  discussed  previously. 

(1)  SSR  Suspense  File 

(2)  Reference  Number  (REFNO)  File 

(3)  Local  Total  Item  Record  (TIR)  File 

c .  Processing 


This  program  module  processes  file  maintenance  ac¬ 
tions  on  the  SSR  Suspense  File  and  the  Local  TIR  File  required 
by  SSR  transactions  and  LIAC  transactions.  It  also  provides  for 
processing  if  file  inquiries.  As  su bs i d i ar i e p  to  this  process, 
certain  val  datlons  take  place  and  report  records  are  formatted 
and  output.  The  validations  will  be  addressed  first  followed  by 
discussion  of  file  maintenance,  inquiry  and  output  processing. 

There  are  three  basic  validations  in  this  program 
module  that  may  result  in  fatal,  rejects.  First,  if  a  duplicate 
record  is  found  on  the  SSR  Suspense  File,  the  file  maintenance 
transaction  is  rejected.  Second,  if  no  matching  record  is  found 
on  the  SSR  Suspense  File  for  a  change  transaction,  the  file  main¬ 
tenance  transaction  is  rejected.  Finally,  if  the  file  maintenance 
transaction  quantities  are  not  equal  to  the  quantities  reflected 
in  the  SSR  Suspense  File  for  a  change  transaction  containing 
corrections  for  technical  or  clerical  errors,  a  reject  will  occur. 
These  rejects  are  handled  as  other  fatal  rejects  discussed  below. 

Since  processing  in  this  module  depends  on  the  type 
of  input  transaction,  each  type  listed  under  Inputs  above  Is 
discussed  separately. 
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(1)  Outgoing  SSR  Transactions.  Outgoing  provision¬ 
ing  and  nonprovisioning  SSR  transactions  having  a  fatal  error 
are  not  recorded  on  the  SSR  Suspense  File,  they  are  output  to 
the  SSR  and  Report  Transaction  File  for  printing  on  the  Outgoing 
SSR  Reject  List.  Outgoing  SSR  Transactions  with  nonfatal  errors 
are  recorded  on  the  SSR  Suspense  File  and  are  output  to  the  SSR 
and  Report  Transaction  File  for  printing  on  the  Outgoing  SSR 
Reject  List.  Valid  outgoing  SSR  transactions  are  posted  to  the 
SSR  Suspense  File  and  output  to  the  SSR  and  Report  Transaction 
File  for  printing  on  the  Outgoing  SSR  List  and  punching  of  Out¬ 
going  SSR  cards. 

( 2 )  Incoming  SSR  Transactions 


Transactions  with  a  fatal  error  are  not  posted 
to  the  SSR  Suspense  File,  but  are  output  on  the  SSR  and  Report 
Transaction  File  for  printing  on  the  Incoming  SSR  Reject  List. 
Transactions  with  a  nonfatal  error  are  posted  to  the  SSR  Suspense 
File  and  output  to  the  SSR  and  Report  Transaction  File  for  print¬ 
ing  on  the  Incoming  SSR  Reject  List.  Valid  transactions  are 
posted  to  the  SSR  Suspense  file  and  output  to  the  SSR  and  Report 
Transaction  File  for  printing  on  the  Incoming  SSR  List  and  punch¬ 
ing  of  Incoming  SSR  cards.  Valid  transactions  undergo  addi¬ 
tional  processing. 

On  incoming  SSRs  containing  an  NSN,  an  asset 
availability  check  is  made  by  drawing  asset  information  from  the 
Local  TIR  File  and  comparing  the  asset  quantity  with  the  sum  of 
the  replenishment  and  retail  quantities  in  the  SSR  transaction. 

If  the  assets  are  greater,  an  advice  transaction  with  Action 
Taken  Code  "YE"  (unconditional  support  accepted)  is  generated 
and  output  to  the  AUTODIN  transaction  file.  This  advice  trans¬ 
action  is  recorded  on  the  SSR  Suspense  File  when  created  and  is 
output  to  the  SSR  and  Report  Transation  File  for  printing  on  the 
Incoming  SSR  List.  Since  this  transaction  is  complete  at  this 
point,  an  ISN  Header  is  created  and  recorded  on  the  file.  If 
the  SSR  quantity  is  greater  *-han  the  asset  quantity,  an  inquiry 
transaction  to  pull  selected  data  from  the  local  TIR  File  is 
generated  and  written  to  a  local  TIR  inquiry  file.  The  local 
TIR  File  printout  resulting  from  this  inquiry  is  used  by  func¬ 
tional  personnel  in  making  an  advice  decision.  When  an  Addi¬ 
tional  Reference  transaction  is  received  with  a  valid  LISSR 
transaction,  a  Local  TIR  inquiry  is  generated.  When  an  Addi¬ 
tional  User  transaction  is  received  with  a  valid  LISSR  transac¬ 
tion,  an  add  user  transaction  is  generated  and  output  to  the  DLSC 
transaction  file.  The  Local  TIR  File  is  also  checked  to  deter¬ 
mine  if  the  SSR  Submitter  is  a  registered  user  of  the  item 
requested.  If  the  submitter  is  not  registered,  a  Local  TIR 
inquiry  is  generated  to  inform  functional  processing  elements 
of  this  condition. 


( 3 )  Outgoing  Line  Item  Advice  Card  (LIAC)  Transac¬ 
tions  .  These  transactions  include  advice  transactions  and  fol¬ 
lowup  response  transactions  for  incoming  LISSR  transactions,  and 
offer  reply  transactions  responding  to  an  offer  advice  transac¬ 
tion  for  outgoing  LISSR  transactions.  Transactions  with  a  fatal 
error  are  output  to  the  SSR  and  Report  Transaction  File.  Trans¬ 
actions  with  a  nonfatal  error  and  valid  transactions  are  recorded 
on  the  SSR  Suspense  File  and  output  to  the  SSR  and  Report  Trans¬ 
action  File.  Valid  advice  transactions  are  also  output  to  the 
AUTODIN  Transaction  File  for  transmittal.  Valid  transactions 
pertaining  to  incoming  LISSR  transactions  are  printed  on  the 
Incoming  SSR  List  and  punched  as  Incoming  SSR  cards.  Invalid 
transactions  are  printed  on  the  Incoming  SSR  Reject  List.  Valid 
transactions  related  to  outgoing  LISSR  transactions  are  printed 
on  the  Outgoing  SSR  List  and  punched  as  Outgoing  SSR  Cards. 
Invalid  transactions  are  printed  on  the  Outgoing  SSR  Reject  List. 
Some  of  these  valid  advice  and  offer  reply  transactions  will 
cause  creation  of  ISN  Headers  indicating  SSR  completion. 

(  4  )  Incoming  Advice,  Offer  Reply  and  Followup 
Response  Transactions 


These  advice  and  followup  response  transactions 
pertain  to  outgoing  LISSR  transactions.  Valid  transactions  of 
these  types  are  posted  to  the  SSR  Suspense  File  and  output  to 
the  SSR  and  Report  Transaction  file  for  printing  on  the  Outgoing 
SSR  List  and  punching  as  Outgoing  SSR  Cards.  Invalid  transac¬ 
tions  of  these  types  with  nonfatal  errors  are  recorded  on  the 
SSR  Suspense  File.  All  transactions  in  error  are  output  to  the 
SSR  and  Report  Transaction  File  for  printing  on  the  Outgoing  SSR 
Reject  List • 


Incoming  offer  reply  transactions  relate  to 
incoming  LISSR  transactions.  Valid  transactions  of  this  type 
are  recorded  on  the  SSR  Suspense  File  and  output  on  the  SSR  and 
Report  Transaction  File  for  printing  on  the  Incoming  SSR  List 
and  punching  as  incoming  SSR  cards.  Invalid  transactions  with 
nonfatal  errors  are  recorded  on  the  SSR  Suspense  File  and  out¬ 
put  on  the  SSR  and  Report  Transaction  File  along  with  transac¬ 
tions  with  fatal  errors  for  printing  on  the  Incoming  SSR  reject 
list. 


When  a  valid  transaction  is  received  containing 
positive  support  advice,  this  program  module  will  automatically 
update  the  local  TIR  File  to  reflect  this  condition  as  well  as 
creating  an  ISN  header  to  show  completion  of  the  LISSR  transac¬ 
tion. 


(5)  Incoming  Followup  Transactions.  Fatal  and  non¬ 
fatal  reject  transactions  are  processed  the  same  as  other  inva¬ 
lid  advice  transactions  for  incoming  LISSR  transactions  discussed 
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above.  Valid  followups  are  matched  against  the  SSR  Suspense 
Kile.  If  no  match  Is  found,  the  transaction  becomes  a  fatal 
reject  as  discussed  in  the  SSR  Edit  and  Validation  Module.  For 
transactions  that  match  where  an  advice  or  followup  response 
transaction  is  present,  a  followup  response  transaction  is  auto¬ 
matically  generated  using  the  ATC  from  the  transaction  on  file 
and  output  to  the  AETODIN  File  for  transmittal.  Also  the  follow¬ 
up  transaction  and  the  followup  response  transaction  are  both 
posted  to  the  SSK  Suspense  File  and  output  to  the  SSR  and  Report 
Transaction  File.  When  an  advice  Tansaction  Is  not  present  for 
a  followup  transaction  matched  to  the  SSR  Suspense  File,  the 
followup  transaction  is  posted  to  the  SSR  Suspense  File  and  both 
the  followup  transaction  and  the  matching  SSR  data  from  the  SSR 
Suspense  File  is  output  to  the  SSR  and  Report  Transaction  File. 
When  this  information  is  conveyed  to  functional  personnel  It 
acts  as  a  r  •  minder  that  advice  is  overdue. 

(6)  Reject  Reentry  Cards.  These  cards  are  both 
generated  as  output  transactions  and  processed  as  input  transac¬ 
tions  in  this  program  module.  When  a  nonfatal  error  is  encoun¬ 
tered  on  Outgoing  PDSSR  or  I,  I S  S  R  transactions.  Reject  Reentry 
Cards  are  generated.  These  Reject  Reentry  Cards  are  a  duplicate 
of  the  input  transaction  and  if  valid  would  have  be^n  output  as 
Outgoing  SSK  Cards.  However,  these  transactions  are  invalid  and 
are  output  separately  to  the  functio  tal  user  for  review,  correc¬ 
tion,  and  reentrv  into  the  SSR  Application.  When  reentered  they 
are  essentially  Outgoing  PDSSR  and  LISSR  transactions  and  are 
processed  bv  this  program  module  and  all  other  program  modules 
as  such. 


( 7  )  S SR  S u  spense  File  Inquiries  (Local  Functional)  . 
These  t r a n s a o r i o n s  ire  processed  last  so  that  the  latest  informa¬ 
tion  in  the  file  is  passed  to  the  functional  user.  The  inquiries 
are  matched  to  the  SSR  Suspense  File  based  on  one  or  more  of  the 
file  control  elements  -  PCC ,  ACT,  AC  F ,  DOR,  ISN,  and  DIC.  For 
example,  it  the  inquiry  specifies  PCC  only,  all  records  on  the 
SSR  Suspense  File  with  matching  PCC  are  extracted  and  output. 

The  requested  dni  i  is  output  to  the  SSR  and  Report  Transaction 
Kile  tor  printing  e  SSR  inquiry  Results. 

d  .  0  u  t  p uts 

( 1 )  SSK  and  Report  Transactions  File.  These  are 
transactions  to  he  passed  to  the  next  program  module. 

( 2 )  DLSC  Transactions  .  These  are  add  user  transac¬ 
tions  generated  by  the  file  maintenance  process  to  be  transmitted 
v  i  a  AUTOni  N  t  .>  1)1  SC  . 
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(3)  Local  Total  Item  Record  (TIR)  Inquiries.  These 
inquiries  will  be  processed  by  another  application  of  CCSS  to 
print  selected  data  from  the  Local  TIR  File.  This  data  will  be 
used  by  functional  elements  in  manual  SSR  processing  segments. 

(  4  )  Automatic  Digital  Network  (AUTODIN)  Transaction 
File.  These  transactions  will  be  electronically  transmitted  to 
other  activities. 

4 .  SSR  Output  Generator 


a  . 

the  SSR  and 


Inputs .  The  single  input  to  this  program  module  is 
Report  Transaction  File. 


b.  Files.  This  program  module  accesses  no  files. 


c .  Processing .  The  processing  in  this 
.'(insists  of  sorting  the  input  transactions  into 
sequence  and  formatting  the  output  products  for 
by  functional  personnel. 


program  module 
output  code 
review  and  action 


d .  Outputs 


(1)  Outgoing  SSR  Cards.  These  are  outgoing  SSR 
transactions  and  advice  transactions  which  successfully  passed 
v  a  1  i  d  a  t  i  o  n  . 

(2)  Incoming  SSR  Cards.  These  are  incoming  SSR 
transactions  and  advice  transactions  which  successfully  passed 
validation. 


(3)  Reject  Reentry  Cards.  These  are  outgoing  PDSSR 
and  LISSR  transactions  rejected  during  processing  due  to  valida- 


t ion  errors  . 

(4) 

Outgoing 

SSR  List . 

This 

is  a  list 

of 

valid 

outgo! ng 

SSR  and 

LIAC  transactions. 

(  5) 

Incoming 

SSR  List. 

This 

is  a  list 

of 

valid 

i ncomlng 

SSR  and 

LIAC  transactions. 

(6) 

Outgoing 

SSR  Reject 

List 

.  This  is 

a 

list 

of 

outgoing 

SSR  transactions 

re  jec  ted  . 

(7) 

Inc  om i ng 

SSR  Reject 

List 

.  This  is 

a 

list 

0  f 

i ncoming 

SSR  transactions 

re  jected  . 

5 .  SSR  File  Surveillance 

a.  Inputs .  There  are  no  transactions  input  to  this 
program  module  to  initiate  processing. 
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b .  Files .  All  tile  s  .»<  cessed  by  this  program  module 
have  been  discussed  earlier  In  this  paragraph. 

(1)  SSR  Suspense  File 

(2)  Reference  Number  (  R  F  F  N  0  )  File 

(3)  Local  Total  Item  Record  (T1R)  File 
c  .  Pro  cessing 

Processing  in  this  program  module  is  a  sequent ia 1 
review  of  each  SSR  record  on  the  SSR  Suspense  File.  Each  record 
is  completely  processed  before  processing  on  the  next  record 
begins.  Each  SSR  record  is  first  checked  to  determine  if  all 
ISN  Headers  are  present  and  complete.  If  so,  and  all  ISN  Headers 
have  been  complete  for  at  least  120  days,  the  NSN  in  each  of  the 
ISN  headers  Is  used  to  access  the  local  TIR  File  and  purge  SSR 
data  from  the  local  TIR  File.  In  addition,  the  entire  SSR  record 
is  purged  from  the  SSR  Suspense  File  at  this  time. 

When  all  outgoing  USSR  transactions  are  not  complete 
in  an  SSR  record,  the  record  will  be  checked  for  followup  trans¬ 
actions.  For  each  one  found  the  process  date  of  the  followup 
transacton  is  checked  to  determine  if  it  is  over  30  days  old,  and 
if  so,  a  new  followup  transaction  will  be  generated  for  transmit¬ 
tal  to  the  IMM.  If  a  followup  transaction  is  not  found  in  the 
record  for  a  LISSR  transaction  with  a  DOR  over  30  days  old,  a 
followup  will  be  generated  for  transmittal  to  the  IMM.  In  each 
case  the  generated  followup  will  be  recorded  in  the  SSR  record 
replacing  the  previous  followup  or  offer  reply  transaction  if  one 
existed.  There  is  a  single  exception  to  this  general  processing 
rule.  When  no  followup  has  been  previously  submitted  or  the  one 
previously  submitted  Is  over  30  days  old  and  an  advice  or  follow¬ 
up  response  Is  present  with  a  process  date  less  than  30  days  old, 
a  followup  transaction  will  not  be  generated. 

d.  Output.  The  single  output  from  this  program  module 
1 8  the  AUTODIN  Transaction  File,  containing  followup  transac¬ 
tions  to  be  transmitted  to  one  or  more  IMMs. 

6 .  Change  Processing 


The  SSR  Application  provides  for  processing  of  changes 
for  both  outgoing  and  Incoming  SSRs.  Changes  to  outgoing  SSRs 
may  be  generated  either  manually  or  automatically  by  the  Auto¬ 
mated  Requirements  Computation  Application.  When  a  change  in 
the  end  item  density  or  maintenance  factors  occurs,  a  recomputa¬ 
tion  may  be  made  by  the  Automated  Requirements  Computation 
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Application.  If  the  recomputation  results  in  a  change  to  the 
retail  or  replenishment  quantities  previously  submitted  on  an 
SSR  transaction,  a  change  SSR  candidate  will  be  generated  and 
passed  to  the  SSR  Application.  These  change  SSR  candidates  are 
processed  the  same  as  other  SSR  candidates  with  the  exception 
that  the  LISSR  transaction  generated  will  contain  a  Type  Change 
Code  (TCC)  of  ”C"  if  one  or  both  quantities  increased,  or  “D"  if 
one  or  both  quantities  decreased.  Other  types  of  changes  are 
generated  on  a  manual  basis. 

The  SSR  change  transactions  generated  on  a  manual  basis 
or  received  from  other  activities  are  input  into  Phase  II  along 
with  other  input  transactions  already  discussed.  Validation  is 
the  same  as  for  any  other  transaction  except  that  the  Type  Change 
Code  is  checked  during  the  duplicate  checks  and  changes  pass  the 
validation  while  other  transactions  do  not.  During  the  file 
maintenance  process,  actions  differ  slightly.  If  the  item  is 
shown  as  complete  on  the  SSR  Suspense  File  only  quantity  dele¬ 
tions  or  item  replacements  are  processed;  other  changes  are 
rejected  as  fatal  rejects.  For  items  not  shown  as  complete  all 
types  of  changes  are  processed.  Changes  to  quantities,  either 
increases  or  decreases,  are  processed  against  the  quantities  in 
the  SSR  Suspense  File.  Replaced  and  superseding  item  changes 
are  validated  to  ensure  there  is  a  superseding  item  change  trans¬ 
action  submitted  for  each  replaced  item  change  transaction. 
Quantities  are  subtracted  from  the  replaced  item  and  the  super¬ 
seding  item  is  processed  as  a  new  SSR  transaction.  Other  changes 
simply  update  the  transaction  in  error.  If  a  deletion  or  re¬ 
placement  change  transaction  causes  the  quantities  in  the  SSR 
Suspense  File  to  go  to  zero,  the  transaction  is  purged  from  the 
SSR  Suspense  File  Immediately.  SSR  data  is  also  purged  from  the 
Local  TIR  File  at  this  point  when  these  conditions  occur. 
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CHAPTER  III 


NAVY 


A.  INTRODUCTION 

The  Uniform  Inventory  Control  Point  (UICP)  System  is  a  stan- 
d'  d  ADP  system  used  at  the  Navy's  two  major  Inventory  Control 
T  ints  (ICPs).  These  two  Navy  ICPs  are  the  principal  operating 
activities  or  SSR  generators  and  processors  in  the  Navy.  The 
U.S.  Navy  Fleet  Material  Support  Office  (FMSO)  is  the  central 
design  activity  responsible  for  the  design,  programming  and 
maintenance  of  the  UICP  System.  The  ICPs  also  maintain  a  staff 
of  ADP  analysts  and  programmers  to  develop  local  applications. 

Some  of  these  applications  may  interface  with  UICP  applications. 

The  UICP  applications  interfacing  with  the  SSR  application 
include  the  P r o v is i oni n g / SS R  Interface  Applications,  the  Whole¬ 
sale  Requirements  Computation  Application  and  the  Provisioning 
Screening  Application.  The  major  SSR  interfaces  developed  by 
the  ICPs  are  in  provisioning  where  three  distinct  automated  sub¬ 
systems  have  been  designed  and  implemented  by  the  ICPs. 

B .  SYSTEMS  DESIGN  PROCESS 

The  Naval  Supply  Systems  Command  (NAVSUP)  maintains  opera¬ 
tional  and  functional  control  over  FMSO,  SPCC  and  ASO.  NAVSUP 
is  responsible  for  supply  support  processing  and  has  the  manage¬ 
ment  responsibility  for  the  design  and  development  of  the  auto¬ 
mated  systems  to  implement  SSR  requirements.  A  Systems  Policy 
and  Concepts  (SPC)  Document  was  developed  by  NAVSUP  to  set  forth 
the  general  functional  requirements  for  SSR  processing  and  con¬ 
tains  the  basic  purpose,  scope,  system  definition,  policy,  des¬ 
cription  and  implementation  plan.  The  SPC  was  coordinated  with 
the  user  activities  prior  to  being  forwarded  to  FMSO  for  devel- 
ment  of  a  Systems  Design  Specification. 

The  organizational  structure  of  FMSO  is  shown  in  Figure  1 1 1 —  1 . 
FMSO  has  a  number  of  assigned  missions,  including  automated  data 
processing  systems  design,  Navy  retail  inventory  management,  pro¬ 
viding  operations  research  analysis  services,  catalog  data  man¬ 
agement  and  development  and  operation  of  the  Navy  Maintenance  and 
Material  Management  System.  There  are  three  major  automated  data 
system  responsibilities  within  its  systems  design  mission,  the  UICP 
System,  the  Uniform  Automated  Data  Processing  System  for  Stock 
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Points  (UADPS-SP)  and  the  Uniform  Automated  Data  Processing  Sys¬ 
tem  for  Ships  (UADPS-Afloat).  This  section  will  be  concerned 
with  the  applications  within  the  UICP  System  that  are  related  to 
the  processing  of  SSRs. 

The  design  and  development  of  the  SSR  application  were  as¬ 
signed  to  the  ICP  Division  of  the  ICP  Systems  Design  and  Proce¬ 
dures  Department.  This  department  has  the  responsibility  of 
participating  in  the  development,  review  and  implementation  of 
new  or  revised  DoD  programs  affecting  the  supply  system  of  the 
Navy.  The  department  determines  the  feasibility  and  practicality 
of  developing  new  or  revising  existing  UICP  Systems  to  accom¬ 
plish  ICP  functions  in  support  of  DoD  programs. 

The  organizational  arrangement  of  the  ICP  Division  and  its 
relationship  to  the  ICP  Systems  Design  and  Procedures  Department 
is  shown  in  Figure  I  1 1  —  1  .  The  development  of  the  Systems  Design 
Specification  was  done  by  the  Supply  Acquisition  Branch.  This 
branch  is  responsible  for  designing,  developing  and  maintaining 
the  supply  acquisition  portion  of  UICP.  In  addition  to  evaluat¬ 
ing  system  performance  and  system  failure,  this  branch  aids  users 
in  the  implementation  and  maintenance  of  the  supply  acquisition 
portion  of  UICP,  and  develops  technical  training  manuals  as  well 
as  training  courses.  The  Systems  Design  Specification  developed 
by  this  branch  is  reviewed  by,  and  final  approval  comes  from 
NAVSU'P.  Once  approved  it  is  forwarded  to  FMSO  for  system  devel¬ 
opment  . 

This  Systems  Design  Specification  then  becomes  the  basis  for 
detailed  system  development,  programming  and  testing  by  FMSO. 

This  detail  system  development  led  to  a  two-phase  SSR  Applica¬ 
tion.  Phase  I  handles  automated  processing  of  outgoing  SSRs  and 
was  to  be  completed  by  1  May  1978  to  coincide  with  the  implemen¬ 
tation  of  the  new  IMM  Manual.  Phase  II  was  to  be  completed  and 
implemented  at  a  later  time  to  deal  with  incoming  SSR  transac¬ 
tions.  This  two-phased  approach  was  a  carry  over  from  the  old 
automated  SSR  application  which  was  also  developed  with  separate 
programs,  files,  etc.,  for  outgoing  and  incoming  SSR  transac¬ 
tions.  When  the  programming  and  testing  are  completed  by  FMSO, 
the  programs  and  other  detailed  documentation  are  forwarded  to 
each  ICP  for  implementation.  Each  ICP  must  set  up  and  test  the 
new  application  to  insure  that  it  interfaces  properly  with  other 
applications  used  by  that  ICP.  When  this  testing  is  completed 
the  application  is  installed  by  the  ICP  and  becomes  fully  imple¬ 
mented  at  that  time. 

C.  DOCUMENTATION 


The  functional  requirements  were  produced  by  NAVSUP  in  the 
form  of  an  SPC  document.  From  the  SPC,  FMSO  developed  a  System 


Design  Specification  which  is  a  detailed  functional  specifica¬ 
tion  for  the  SSR  application.  Detailed  computer  systems  speci¬ 
fications  from  which  computer  programmers  work,  are  developed  from 
the  System  Design  Specification.  There  are  seven  levels  of  de¬ 
tailed  systems  specifications  called  Data  Processing  Specifica¬ 
tions  (DPSs)  and  listed  below. 

1.  DPS-1;  Application/Operation  Summary.  This  level  in¬ 
cludes  a  list  of  program  numbers  and  names  included  in  the 
application  as  well  as  a  run  chart  showing  the  inputs,  outputs, 
and  files  used  for  each  program. 

2.  DPS-2;  Program  Specifications.  These  are  detailed  pro¬ 
gram  specifications  including  a  description  of  each  input,  output 
and  file  used  in  the  program.  Also  included  is  a  detailed  pro¬ 
gram  flowchart  with  narrative  descriptions  for  each  processing 
event.  Validation  criteria  and  processing  codes  assigned  or 
used  in  the  program  may  appear  in  this  level  of  documentation. 

3 .  DPS-3;  EAM  Input/Output  Support  Instructions.  These 
instructions  contain  specific  EAM  or  clerical  requirements  for 
preparation  of  inputs  and  processing  of  outputs. 

4.  DPS- 4;  Output  Listing  and  Report  Procedures.  These  pro¬ 
cedures  contain  instructions  for  bursting,  booking,  binding  and 
distributing  listings  and  reports. 

5.  DPS-5;  Satellite  Computer  Requirements.  This  documenta¬ 
tion  defines  processing  to  be  accomplished  by  peripheral/satellite 
computer  systems  to  support  the  primary  system  for  the  applica¬ 
tion. 

6.  DPS-6;  Program  Documentation.  This  level  of  documenta¬ 
tion  includes  narratives  and  flowcharts  development  by  the  com¬ 
puter  programmer,  source  program  listings  and  test  data. 

7.  DPS-7;  Operations  Documentation.  All  necessary  infor¬ 
mation  to  run  a  given  program  is  included  in  this  documentation. 

In  addition  to  this,  a  test  plan  is  usually  developed  for 
testing  of  the  application,  and  support  procedures  are  written 
and  published  for  use  by  the  ICPs.  A  training  package  was  not 
developed  for  the  SSR  application  by  FMSO;  this  became  the 
responsibility  of  each  implementing  ICP.  The  organization, 
level  of  detail,  and  availability  of  published  UICP  documenta¬ 
tion  'MSO  was  generally  good. 

Docum.  ation  at  the  ICP  level  generally  consists  of  detailed 
systems  flowcharts,  detailed  program  level  requirements,  program 
listings  and  operational  requirements. 
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D.  SYSTEMS  OVERVIEW 


The  SSR  system  in  the  Navy  was  designed  as  a  single  applica¬ 
tion  with  a  separate  program  stream  for  incoming  SSRs  and  one 
for  outgoing  SSRs.  The  outgoing  SSR  portion  of  the  application 
was  designed  to  be  compatible  with  two  different  P r o v i s i on i n g / SS R 
Interface  Applications;  one  for  SPCC  and  one  for  ASO.  The  Provi- 
sioning/SSR  Interface  Applications  were  designed  to  interface 
with  two  different  provisioning  applications  unique  to  SPCC  and 
one  unique  to  ASO.  The  provisioning  applications  are  designed, 
developed  and  maintained  by  the  ICPs.  The  P r o v i s i on i ng / SS R 
Interfaces  although  designed  for  SPCC  and  ASO  operations,  are 
centrally  maintained  as  UICP  programs. 

The  three  provisioning  applications  are:  the  SPCC  Electronics 

Provisioning  Subsystem;  the  SPCC  Hull,  Mechanical,  Electrical, 
and  Ordnance  (HME&O)  Provisioning  Subsystem;  and  the  ASO  Provi¬ 
sioning  Subsystem.  These  subsystems  interface  with  other  appli¬ 
cations  In  generating  SSR  transactions.  To  show  these  subsystems 
and  their  related  interfacing  applications  on  a  single  Systems 
Overview  Chart  would  result  in  an  unwieldy  and  potentially  con¬ 
fusing  diagram.  Therefore,  each  provisioning  subsystem  and  its 
related  applications  is  shown  on  a  single  chart  with  each  chart 
being  discussed  from  beginning  to  end  before  presenting  the  next 
chart.  The  automated  systems  at  SPCC  generate  initial  submission 
SS’i  transactions  only.  It  is  not  known  if  the  ASO  automated 
system  generates  initial  submissions  only  or  both  initial  and 
change  submissions.  Before  presenting  the  first  Systems  Over¬ 
view  Chart,  an  application  used  by  management  in  monitoring  the 
progress  of  provisioning  processing  through  any  of  the  provi¬ 
sioning  systems  is  discussed. 

1  .  UICP  Provisioning  Scheduling  and  Monitoring  Application 

This  is  a  stand-alone  application  not  shown  on  any  Sys¬ 
tems  Overview  Chart  because  it  does  not  interface  directly  with 
the  SSR  process;  however,  it  does  have  an  impact  on  the  timeli¬ 
ness  of  SSR  generation.  The  purpose  of  this  application  is  to 
provide  an  automated  method  of  scheduling  and  monitoring  provi¬ 
sioning  projects  from  the  issuing  of  contracts  to  the  prepara¬ 
tion  of  pu r c ha s e / s upp ly  support  documents  and  allows  generation 
of  management  reports  both  on  a  cyclic  and  special  request  basis. 
Under  this  system  the  provisioning  operation  is  divided  into  a 
series  of  major  events  (maximum  of  13)  performed  by  suborganiza- 
tional  elements  within  the  ICP.  The  major  events  to  be  moni¬ 
tored  and  the  scheduled  completion  times  for  these  events  are 
defined  by  each  ICP,  and  up  to  32  of  these  e ven t / comp le t i on  time 
combinations  may  be  preprogrammed  into  the  computer.  Events  and 
schedules  may  vary  from  project  to  project.  When  a  provisioning 


effort  is  started,  one  of  these  preprogrammed  provisioning  sched¬ 
ules  may  then  be  used  or  another  set  of  events  and  completion 
times  may  be  manually  determined  and  entered  into  the  computer 
for  use  as  a  provisioning  schedule. 

When  a  provisioning  project  is  entered  into  the  applica¬ 
tion,  a  series  of  update  cards  are  automatically  produced;  one 
card  for  each  major  event  in  the  provisioning  schedule  is  out¬ 
put.  The  progress  of  the  provisioning  project  is  monitored 
through  each  major  event  using  these  update  cards  which  are  input 
to  this  application  by  each  su bo r g an i z a t i ona 1  element  when  a  major 
event  has  been  completed.  Update  cards  may  also  be  manually 
generated  and  input  if  the  provisioning  package  is  delayed  to 
put  the  package  in  a  hold  status;  the  reason  for  the  delay  (e.g., 
inadequate  technical  data)  is  coded  on  the  input  card.  Reports 
are  produced  by  this  application  showing  the  number  of  items  and 
events  completed  on  time  and  those  overdue  by  organizational 
element  and  Provisioning  Document  Control  Number  (PDCN).  The 
reports  are  designed  to  show  actions  taken  in  each  individual 
provisioning  project  during  the  reporting  period  or  cycle  and 
does  not  Include  a  summary  of  event  times  for  different  provi¬ 
sioning  projects.  These  reports  are  used  to  follow  the  progress 
of  a  provisioning  project  until  the  provisioning  data  is  final¬ 
ized  and  entered  in  major  ICP  files.  This  application  does  not 
provide  further  status  or  monitorship  through  the  su;  )ly  support 
process . 


2.  SPCC  Automated  Electronics  System  Overview.  e  auto¬ 

mated  provisioning  subsystem  and  interfacing  ah  •licati  <ns  shown 
in  Figure  I  I  I  —  2  are  used  at  SPCC  in  the  provisi  ning  of  electro¬ 
nics  components.  The  electronics  provisioning  subsystem  is  a 
local  SPCC  unique  application  designed,  developed,  and  maintained 
by  the  SPCC.  This  subsystem  interfaces  with  two  standard  UICP 
applications  as  shown  in  Figure  1 1  I  —  2  ;  these  are  toe  UICP  Provi¬ 
sioning  Screening  Application  and  the  UICP  Wholesali  Requirements 
Computation  Application.  The  UICP  Wholesale  Requirements  Computa¬ 
tion  Application  then  interfaces  with  the  UICP  SPCC  Provisioning/ 
SSR  Interface  Application  which  generates  SSR  transactions  for 
processing  in  the  UICP  SSR  Application.  This  subsystem  and  each 
of  these  applications  are  discussed  on  a  general  basis. 


a.  SPCC  Electronics  Provisioning  Subsystem.  The  Elec¬ 
tronics  Provisioning  Subsystem  is  used  to  accomplish  provisioning 
processing  from  the  initial  receipt  of  provisioning  documenta¬ 
tion  from  the  contractor  through  item  screening,  item  selection 
(SM&R  coding),  item  management  coding,  file  establishment  and 
maintenance,  and  initial  requirements  determination.  Major  in¬ 
puts,  files,  processes  and  outputs  are  discussed  below. 
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(1)  Inputs  .  Inputs  to  this  subsystem  Include  Pro¬ 
visioning  Technical  Data  submitted  by  the  contractor,  error  cor¬ 
rections  and  computation  header  transactions. 

(a)  Provisioning  Technical  Data.  This  provi¬ 
sioning  data  is  contractor  furnished  in  card  or  tape  form. 

(b)  Error  Corrections.  Correction  transactions 
for  provisioning  technical  data  found  in  error. 

(c)  Computation  Header  Transactions.  These 
transactions  provide  data  required  by  the  provisioning  subsystem 
to  compute  requirements. 

(2)  Files  .  Files  accessed  by  this  subsystem  are 
the  Weapons  Systems  File  (WSF),  Local  TIR  File,  Program  Support 
Interest  (PSI)  File,  Technical  Reference  File  (TRF),  Cross 
Reference  File  (CRF),  Master  Allowance  Parts  List  (MAPL)  File, 
Validation  Suspense  File,  and  Supply  Management  Suspense  (SMS) 
File. 


( a )  Weapons  Systems  File  (WSF)  .  This  is  a 
major  UICP  disk  file  which  contains  all  items  used  in  a  specific 
weapon  system.  The  file  contains  all  items  within  each  equip¬ 
ment/component  within  each  system  used  by  a  specific  end  item  or 
weapons  system. 


(b)  Local  Total  Item  Record  (TIR)  File.  This 
UICP  disk  file  is  called  the  Master  Data  File  in  the  Navy  and 
contains  detailed  supply,  technical  and  cost  data  on  all  items 
currently  managed  by  the  ICP.  It  also  contains  data  on  part 
numbered  items  to  be  managed  by  another  ICP  until  an  NSN  is 
received  for  the  item.  These  part  numbered  items  arc  assigned 
an  Activity  Control  Number  (ACN)  which  is  similar  to  an  NSN. 

The  file  is  sequenced  on  NI1N  or  ACN  and  each  item  consists  of  a 
fixed  common  data  segment  with  a  variable  number  of  additional 
data  segments. 


( c )  Program  Support  Interest  (P S  I  )  F i  1  e  .  This 
UICP  disk  file  contains  the  same  type  of  data  as  the  local  TIR 
file  and  also  has  parallel  organization.  This  file  contains 
items  with  NSNs  used  by  the  Navy  in  one  or  more  weapons  systems 
that  are  managed  by  an  activity  other  than  SPCC. 

(d)  Technical  Reference  File  (TRF).  This  UICP 
disk  file  is  organized  like  the  local  TIR  file,  but  contains 
nonstocked  items  under  resident  ICP  cognizance  not  having  an 
NSN.  This  file  also  contains  historical  data  for  items  which 
the  ICP  has  withdrawn  Interest  or  for  items  which  have  been 
superseded . 
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(e)  Cross  Reference  File  (CRF).  This  UICP 
disk  file  serves  as  an  index  for  FSCM/Par t  Number  Combinations 
to  NUN  or  ACN  n  the  local  TIR  File,  PSI  File  and  TRF . 

( f )  Master  Allowance  Parts  List  (MAPL)  File. 

This  local  SPCC  magnetic  tape  file  contains  a  top  down  breakdown 
of  repair  parts  in  electronics  equipment. 

(g)  Validation  Suspense  File.  This  local  SPCC 
magnetic  tape  file  contains  records  in  a  provisioning  package 
which  have  passed  validation. 

( h )  Supply  Management  Suspense  (SMS)  File. 

This  local  SPCC  magnetic  tape  file  contains  items  awaiting  screen¬ 
ing  results  from  DLSC. 

( 3 )  Processing 

Transactions  are  processed  through  the  SPCC 
Electronics  Provisioning  Subsystem  on  a  provisioning  package 
basis.  This  subsystem  is  executed  on  a  twice  weekly  cycle  in  a 
batch  oriented  mode. 

Provisioning  technical  data  entered  into  this 
subsystem  is  first  validated  for  format  and  content  with  errors 
listed  for  correction  and  valid  transactions  written  to  the  Vali¬ 
dation  Suspense  File.  When  all  items  in  a  provisioning  package 
pass  validation,  the  package  is  extracted  from  the  validation 
suspense  file  for  catalog  data  screening.  Part  number  items  are 
matched  against  the  CRF  to  determine  if  NSNs  already  exist  for 
these  items  within  the  UICP  files  resident  at  SPCC.  The  NSNs 
found  on  the  CRF  for  part  numbered  items  and  the  NSNs  for  the 
remainder  of  the  items  are  then  screened  for  catalog  data  against 
the  UICP  files  resident  at  SPCC.  Part  numbers  not  found  on  the 
CRF  and  NSNs  not  residing  on  UICP  files  are  passed  to  the  UICP 
Provisioning  Screening  Application  discussed  below  for  screening 
against  DLSC  files.  The  provisioning  package  is  lodged  in  the 
SMS  file  awaiting  processing  of  DLSC  screening  replies.  When 
local  SPCC  and  DLSC  screening  results  have  been  reviewed  by 
functional  personnel  and  IMC  and  FSC  have  been  assigned  for  new 
items,  the  provisioning  package  is  extracted  from  the  SMS  File 
and  file  maintenance  transactions  are  created  to  load  or  update 
the  WSF,  local  TIR,  PSI,  TRF  and  MAPL  files. 

After  these  files  have  been  loaded /updated  pro¬ 
cessing  is  suspended  until  the  Computation  Header  Transactions 
are  input.  Input  of  these  transactions  initiates  a  file  extract 
from  the  WSF,  local  TIR  File  and  PSI  File  of  provisioning  data 
required  to  accomplish  requirements  determination  processing  and 
create  SSRs.  The  electronics  provisioning  subsystem  computes 
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the  allowance  quantities  for  all  items  in  the  provisioning  pack¬ 
age.  This  allowance  quantity  is  used  as  the  retail  quantity  in 
SSR  transactions.  This  subsystem  also  computes  wholesale  quan¬ 
tities  for  SSR  candidate  items.  This  data  is  then  output  to  the 
Computation  Transaction  File  which  is  processed  in  the  Wholesale 
Requirements  Computation  Application. 

(4)  Outputs  .  Outputs  from  this  subsystem  include 
DLSC  screening  requests,  Computation  Transactions,  Validation 
Error  List,  and  Functional  Outputs  as  shown  in  Figure  III-2. 

(a)  DLSC  Screening  Requests.  These  are  input 
transactions  to  the  Provisioning  Screening  Application. 

(b)  Computation  Transactions.  These  are  input 
transactions  to  the  Wholesale  Requirements  Computation  Applica¬ 
tion. 


(c)  Validation  Error  List.  Provisioning  tech¬ 
nical  data  which  does  not  pass  initial  validation  is  output  on 
this  list. 


(d)  Functional  Outputs.  There  are  several 
functional  outputs  in  this  subsystem  which  are  reviewed  and  acted 
upon  by  functional  personnel  which  are  not  listed  separately  here. 

b.  UICP  Provisioning  Screening  Application.  This  UICP 
application  provides  the  capability  to  screen  NSNs  and  Reference 
Numbers  against  the  DIDSTIR  File  at  DLSC  and  against  local  ICP 
files. 


(1)  Inputs .  Inputs  to  this  application  include 
screening  request  transactions  and  DLSC  responses. 

(a)  Screening  Requests.  These  are  transactions 
requesting  screening  to  be  performed. 

(b)  DLSC  Responses.  These  are  responses  to 
the  screening  requests  sent  to  DLSC. 

(2)  Files.  The  seven  files  accessed  by  this  appli¬ 
cation  include  the  Local  TIR  File,  PSI  File,  TRF ,  CRF ,  MOE  Rule 
File,  and  Old  NIIN  Reference  File. 

( a )  Local  Total  Item  Record  (TIR)  File. 

( b )  Program  Support  Interest  (PSI)  File. 

( c )  Technical  Reference  File  (TRF). 

( d )  Cross  Reference  File  (CRF). 
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( e )  Major  Organizational  Entity  (MOE)  Rule 
File.  This  is  a  UICP  disk  file  containing  valid  MOE  Rule  data. 

(f)  Old  NUN  Reference  (ONR)  File.  This  is  a 
UICP  cross-reference  file  which  relates  old  NIINs  to  the  new 
NIIN.  The  file  resides  on  disk,  is  sequenced  on  old  NIIN,  and 
has  fixed  length  records. 

(g)  DLSC  Suspense  File.  This  UICP  magnetic 
tape  file  contains  a  record  of  all  screening  requests  sent  to 
DLSC  for  which  a  response  has  not  been  received.  If  a  response 
is  not  received  within  seven  days  (14  days  for  requests  sent  via 
mail)  a  followup  request  is  automatically  generated.  If  a  reply 
has  still  not  been  received  14  days  after  the  followup  request 
was  sent,  the  transaction  is  purged  from  the  Suspense  File  and 
written  to  an  output  tape  which  is  printed  for  functional  noti¬ 
fication/action. 

( 3 )  Processing 

This  application  validates  input  screening 
request  transactions  and  formats  them  into  DLSC  screening  trans¬ 
actions.  DLSC  screening  transactions  are  written  to  the  DLSC 
Suspense  File  when  transmitted  to  DLSC  for  processing.  They  are 
purged  from  this  file  when  a  response  is  received  from  DLSC. 

Two  types  of  response  transactions  are  returned  from  DLSC;  header 
response  transactions  and  item  response  transactions. 

When  a  DLSC  screening  transaction  is  found  to 
be  in  error,  a  reject  header  response  transaction  and  reject 
item  response  transaction  are  returned.  These  reject  transac¬ 
tions  are  printed  on  the  Reject  List. 

All  other  header  response  transactions  are 
printed  as  Edited  DLSC  Data.  Item  response  transactions  fall 
into  two  categories;  those  not  requiring  further  automated  pro¬ 
cessing  and  those  requiring  further  automated  processing. 

Item  response  transactions  not  requiring 
further  automated  processing  are  those  indicating  a  no  match 
condition  or  a  match  to  a  security  classified  item.  Also  the 
functional  user  may  suppress  further  automated  processing  by 
placing  an  alphabetic  character  in  the  seventh  position  of  the 
submitter  control  number.  These  item  response  transactions  are 
printed  as  Edited  DLSC  Data. 

The  remaining  item  response  transactions  require 
further  automated  processing.  When  a  DLSC  response  indicates  a 
match  to  multiple  NSNs,  this  application  attempts  to  select  a 
preferred  NSN  from  those  matched  and  a  preferred  MOE  Rule  for 


Che  NSN  selected.  The  preferred  NSN  is  selected  by  prioritizing 
the  standardization  code  for  each  NSN  returned.  The  NSN  with 
the  highest  priority  standardization  code  is  the  preferred  NSN. 
When  a  preferred  NSN  cannot  be  determined  using  the  standardiza¬ 
tion  code,  MOE  Rule  data  is  extracted  from  the  MOE  Rule  file  and 
a  prioritization  by  Level  of  Authority  takes  place.  Again  the 
NSN  with  the  highest  priority  MOE  Rule  is  selected  as  the  pre¬ 
ferred  NSN.  When  multiple  MOE  Rules  are  returned  from  DLSC  for 
a  single  NSN  or  if  a  preferred  NSN  was  selected,  a  preferred  MOE 
Rule  is  attempted  to  be  selected.  Each  MOE  Rule  is  prioritized 
by  Level  of  Authority  with  the  MOE  Rule  assigned  the  highest 
priority  selected  as  the  preferred  MOE  Rule.  If  two  or  more  MOE 
Rules  have  equally  high  priority,  the  Navy  MOE  Rule  is  selected 
as  the  preferred  MOE  Rule;  otherwise  a  preferred  MOE  Rule  is  not 
selected  . 


The  preferred  NSN  identified  through  this  pro¬ 
cedure  is  then  screened  against  the  local  ICP  files  shown  on 
Figure  III-2.  When  the  DLSC  response  indicates  a  match  to  a 
single  NSN,  this  NSN  is  also  screened  against  local  ICP  files. 

If  multiple  NSNs  were  returned  in  a  DLSC  response  and  no  pre¬ 
ferred  NSN  could  be  determined,  each  NSN  returned  if  screened 
against  the  local  ICP  files.  For  NSNs  screened  against  local 
ICP  files,  both  DLSC  data  and  local  file  data  (when  there  is  a 
local  file  match)  are  printed  as  Edited  DLSC  Data  for  functional 
use  in  the  provisioning  process. 

(4)  Outputs .  Outputs  from  this  application  include 
DLSC  Screening  Requests,  DLSC  Re submi t t a 1 s ,  Reject  List  and 
Edited  DLSC  Data. 


(a)  DLSC  Screening  Requests.  These  are  card 
or  magnetic  tape  transactions  to  be  forwarded  to  DLSC  via  mail 
or  AUTODIN. 


(b)  DLSC  Re s ubm i 1 1 a  1 s  .  These  are  screening 
transactions  resubmitted  to  DLSC  because  a  response  had  not  been 
received  within  14  days  to  the  previously  submitted  transac- 
t  ions  . 


(c)  Reject  List.  This  list  contains  transac¬ 
tions  rejected  by  this  application  or  rejected  by  DLSC. 

(d)  Edited  DLSC  Data  .  This  list  contains  data 
returned  from  DLSC  and  the  results  of  any  local  screening  action 
as  well  as  the  preferred  NSN  and  preferred  MOE  Rule  from  the 
automated  decision  making  process  when  a  decision  was  able  to  be 
reached . 
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c .  UICP  Wholesale  Requirements  Computation  Application. 
This  UICP  Application  is  shown  on  the  Systems  Overview  Chart  to 
point  out  that  Provisioning  packages  pass  through  it.  This 
application  computes  System  Stock  (Wholesale)  Requirements  for 
SPCC  managed  items  only  and  is  the  basis  for  generation  of  pur¬ 
chase  transactions  and  planned  requirements  transactions  in  the 
UICP  SPCC  Pr o v is  ion i ng / SS R  Interface  Application. 

d .  UICP  SPCC  Pr o v 1 s ion  1 ng / S SR  Interface  Application. 

This  UICP  application  was  designed  to  provide  an  interface  of 
the  local  SPCC  provisioning  subsystems,  the  UICP  Wholesale 
Requirements  Computation  Application  and  the  UICP  SSR  Applica¬ 
tion.  This  application  splits  out  supported  items  to  be  managed 
by  SPCC  and  automatically  generates  modified  purchase  transac¬ 
tions  and  planned  requirements  transactions  for  these  items. 

SSR  candidates  are  examined  against  SPCC  established  criteria  in 
this  application  and  are  generated  SSR  transactions  f  r  candidates 
meeting  these  criteria.  Items  in  the  provisioning  package  deter¬ 
mined  to  be  nonsupport  items  are  output  on  the  ACN  History  File. 

(1)  Inputs.  There  are  two  inputs  to  this  applica¬ 
tion.  The  first  is  the  transaction  file  from  the  Wholesale 
Requirements  Computation  Application.  The  second  is  manually 
generated  transactions  to  change  or  delete  records  from  the 
Interface  Suspense  File. 

(2)  Files  .  Files  accessed  by  this  application 
include  the  Local  TIR  File,  PSI  File,  ONR  File  and  Interface 
Suspense  File. 


(a) 

Local  Total  Item  Record 

(TIR) 

File  . 

(b) 

Program  Support  Interest 

(PSI) 

File. 

(c) 

Old  NUN  Reference 

(ONR) 

File  . 

(d) 

Interface  Suspense 

File 

( ISF)  . 

This  UICP 

magnetic  tape  file  contains  all  records  entered  into  this  appli¬ 
cation  from  the  Wholesale  Requirements  Computation  Application. 
Records  on  this  file  may  be  changed  or  deleted,  and  normally  re¬ 
main  on  the  file  for  one  year  before  they  are  automatically  purged. 

(3 )  Processing 

Processing  in  this  application  is  on  a  provi¬ 
sioning  package  basis.  This  application  is  a  batch  processing 
operation  normally  executed  four  times  a  month.  Initial  inputs 
to  the  application  are  validated  for  correct  and  complete  infor¬ 
mation  and  placed  on  the  ISF  after  which  a  Provisioning  Computa¬ 
tion  Review  List  is  produced.  This  List  is  reviewed  by  func¬ 
tional  personnel  and  is  the  basis  for  changes  to  or  deletions 
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from  the  Interface  Suspense  File.  In  addition,  error  lists  are 
prepared  for  functional  review  and  correction  resulting  from  in¬ 
valid  input  data.  Part  of  the  validation  process  done  by  this 
application  is  checking  the  NSN  or  ACN  against  the  local  TIR  File, 
PSI  File,  and  ONR  File  to  ensure  it  is  still  valid  and  current. 
When  a  provisioning  package  is  found  to  be  error  free,  it  con¬ 
tinues  processing  through  this  application. 

Modified  Purchase  Transactions  and  Planned  Re¬ 
quirements  Transactions  are  created  for  SPCC  managed  items.  Non  - 
SPCC  managed  items  are  subjected  to  a  series  of  tests  to  deter¬ 
mine  whether  or  not  an  SSR  transaction  will  be  created.  The 
series  of  tests  including  the  test  criteria  and  positive  and 
negative  actions  are  shown  in  Figure  III-3.  Note  that  SSR  trans¬ 
actions  are  not  created  only  when  both  the  retail  and  replenish¬ 
ment  quantities  are  zero  (test  number  2)  or  when  none  of  the  other 
test  criteria  is  met.  When  an  SSR  transaction  is  not  generated 
for  an  item,  the  item  retains  its  ACN  and  is  output  to  the  ACN 
History  File. 


All  SSR  transactions  generated  are  written  to 
the  SSR  transaction  file  for  input  to  the  UICP  SSR  Application. 

A  cataloging  action  list  is  produced  for  those 
items  which  require  cataloging  action  by  SPCC  and  a  data  change 
file  is  created  to  update  the  Local  TIR,  PSI,  TRF,  and  MAPL 
Files. 


(A)  Outputs .  Outputs  from  this  application  include 
the  Provisioning  Computation  Review  List,  High  Dollar  Review 
List,  Transaction  Error  List,  Interface  Suspense  File  List,  Modi¬ 
fied  Purchase  transactions,  Planned  Requirements  transactions, 

ACN  History  File  and  SSR  transactions  file. 

(a)  Provisioning  Computation  Review  List.  This 
list  contains  items  input  in  the  current  cycle  which  were  found 
to  be  valid. 


(b)  High  Dollar  Review  List.  This  is  produced 
at  the  same  time  as  the  Provisioning  Computation  Review  List  for 
items  that  have  an  extended  dollar  value  of  $25,000.00  or  more. 

(c)  Transaction  Error  List.  This  list  con¬ 
tains  all  input  transactions  failing  validation. 

(d)  Interface  Suspense  File  List.  This  is  a 
printout  of  all  provisioning  packages  currently  located  on  the 
Interface  Suspense  File. 
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(e)  Modified  Purchase  Transactions.  These 
transactions  are  passed  to  another  application  to  initiate  pur¬ 
chase  requests  on  items  retained  by  the  ICP  for  management. 

(f)  Planned  Requirement  Transactions.  These 
are  planned  requirements  of  SPCC  managed  items  and  are  fed  to 
the  planned  requirements  application  to  be  lodged  in  SPCC  files 
for  support,  budgeting,  and  funding  considerations.  As  used  in 
V I C P ,  the  term  "Planned  Requirement”  identifies  any  known  or 
anticipated,  funded  or  unfunded  project  or  program  related  re¬ 
quirement  from  either  Navy  or  DoD  customers  which  cannot  be  pre 
dieted  within  the  I'ICP  cyclic  levels  forecasting  techniques. 
Within  this  broad  definition,  planned  requirements  range  from 
the  highest  priority  funded  requirement  of  the  approved  force 
mobilization  acquisition  objective  to  unfunded  anticipated 
future  requirements  which  are  included  in  the  System  Retention 
Limit  to  preclude  disposal  of  available  assets. 

( g )  Activity  Control  Number  (ACN)  History 
File.  These  are  items  without  NSNs  which  did  not  qualify  for 
s lockage  or  SSR  generation  using  SPCC  criteria.  These  items 

•  •  v  e  n  t  u a  1 1 v  migrate  to  the  T  R  F  . 

(h)  SSR  Transactions  File.  These  are  SSR 
:  r  unmet  ions  to  be  fed  to  the  SSR  application. 

e.  SSR  Application 


A  general  discussion  of  this  application  is  given 
•  complete  the  system  overview  with  a  detailed  discussion 
is  application  given  later.  Although,  the  SPCC  Electronic 
i  nine  is  being  specifically  addressed  in  this  subsystem/ 
•at  ion  stream,  the  discussion  of  the  SSR  Application  which 
w  :>  applies  equally  to  SSR  transactions  generated  by  the 

provisioning  and  ASO  provisioning  systems  discussed 


Outgoing  SSR  processing  performed  by  this  applica- 
t  ion  includes  validation  and  file  maintenance  of  SSR  transac¬ 
tions,  generation  of  internal  and  external  followups,  and  file 
maintenance  of  advice  and  followup  response  transactions.  In¬ 
coming  SSR  processing  performed  includes  validation  with  automa 
tic  generation  of  reject  advice  transactions,  support  decision 
of  "YE"  (unconditional  support  accepted)  for  SSR  transactions 
containing  an  NSN,  file  maintenance,  generation  of  cataloging 
transactions,  generation  of  planned  requirements  transactions, 
and  generation  of  followup  response  transactions. 

(1)  Inputs  .  Inputs  to  this  application  include 
Program  Data  Record  (PDR)  Updates;  Outgoing  Provisioning  SSR 
Transactions;  and  SSR  Transactions,  LIACs,  and  Local  Inquiry 
Transactions . 


(a)  Program  Data  Record  (PDR)  Updat e s .  These 
are  transactions  to  update  the  PDR  File  which  contains  program 
data  used  in  generating  SSR  Header  Cards  (PDSSRs). 


( b )  Outgoing  Provisioning  SSR  Transactions  . 
These  are  SSR  transactions  generated  on  an  automated  basis  ini¬ 
tiated  by  one  of  the  Provisioning  Subsystems. 


( c )  SSR  Transactions,  LIACs,  and  Local  Inquiry 
Transactions  .  Included  in  this  group  are  manually  generated 
provisioning  and  no n p r o v i s i o n i n g  outgoing  SSR  transactions,  in¬ 
coming  SSR  transactions,  outgoing  advice  transactions,  incoming 
advice  transactions,  incoming  followup  transactions  and  local 
inquiries  into  the  SICC  SSR  Status  File. 


(2)  Files.  There  are  six  files  accessed  by  this 
application.  They  are  the  PDR  File,  Suppliers  Data  File,  SICC 
SSR  Suspense  File,  WIMM  SSR  Suspense  File,  Local  TIR  File,  and 
MOE  Rule  File. 


( a )  Program  Data  Record  (PDR)  File.  This 
magnetic  tape  file  contains  provisioning  program  data  some  of 
which  is  used  for  SSR  header  cards  and  some  of  which  is  used  for 
local  processing  only. 


(b)  Suppliers  Data  File.  This  magnetic  tape 
file  serves  as  a  cross-reference  of  FSCM  to  contractor  address. 


(c)  SICC  SSR  Suspense  File.  This  magnetic 
tape  file  serves  as  an  active,  suspense  and  historical  file  for 
valid  outgoing  SSR  transactions.  Invalid  SSR  transactions  are 
not  posted  to  this  file. 

(d)  WIMM  SSR  Suspense  File.  This  magnetic 
tape  file  serves  as  an  active,  suspense  and  historical  file  for 
incoming  SSR  transactions.  It  contains  both  valid  and  invalid 
transactions  • 


( e )  Local  Total  Item  Record  (TIR)  File . 

( f )  Major  Organizational  Entity  (MOE)  Rule  File. 

(3 )  Processing 

The  initial  processing  action  taken  in  outgoing 
SSR  processing  is  an  update  of  the  PDR  File.  The  SSR  transactions 
generated  on  a  manual  or  automated  basis  are  input  and  sorted 
for  validation.  Outgoing  SSR  transactions  which  do  not  pass  vali¬ 
dation  are  not  posted  to  the  SICC  SSR  Suspense  File,  but  are  out¬ 
put  for  manual  review.  Transactions  that  pass  validation  are 
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posted  to  the  SICC  SSR  Suspense  File  and  output  for  mailing  to 
the  IMM.  File  maintenance  processing  includes  generation  and 
output  of  internal  and  external  followups  when  required  actions 
are  overdue.  Advice  is  posted  to  the  Suspense  File  and  output 
to  the  functional  area  as  a  notification.  Local  Inquiry  pro¬ 
cessing  takes  place  last  so  the  latest  available  information  is 
made  available  to  the  requestor.  The  various  reports,  listings 
and  cards  produced  during  this  processing  are  described  in  the 
detailed  SSR  application  description. 

Incoming  SSR  transactions  are  also  sorted  and 
validated  with  both  valid  and  invalid  SSR  transactions  being 
posted  to  the  WIMM  SSR  Suspense  File.  Invalid  SSR  transactions 
are  listed  and  reject  advice  cards  are  automatically  created  for 
return  to  the  submitter.  Valid  incoming  SSRs  with  an  NSN  are 
matched  to  the  local  TIR  file.  When  a  match  is  found,  the  MOE 
Rule  in  the  SSR  transaction  is  compared  to  the  MOE  Rule  File  for 
validity  and  the  MOE  Rule  in  the  local  TIR  file  for  generation 
of  a  DLSC  update  transaction  (e.g.,  add  user  transaction).  An 
accept  advice  transaction  with  ATC  "YE”  (unconditional  support 
accepted)  is  generated  for  valid  incoming  SSR  transactions  that 
match  the  local  TIR  File  and  complete  MOE  Rule  processing.  Valid 
incoming  SSR  transactions  with  NSNs  meeting  specific  ICP  criteria 
and  SSR  transactions  without  NSNs  are  output  for  manual  review. 
When  an  accept  advice  is  generated  for  an  SSR,  appropriate  Planned 
Requirements  Transactions  are  created  to  allow  forecasting  of 
additional  assets  to  meet  SSR  requirements  by  the  item  manager. 

A  detailed  description  of  outputs  is  given  below. 

(4)  Outputs .  Outputs  are  simply  listed  here  with  a 
detailed  description  given  in  the  Detailed  SSR  Application  Des¬ 
cription  below. 

(a)  DLSC  Updates 

(b)  Planned  Requirements  Transactions 

(c)  SSR  Advice  Followups 

(d)  Error/Manual  Review  Cards 

(e)  Functional  Reports/Local  Inquiry  Results 

3.  SPCC  Automated  HME&O  System  Overview.  The  System  Over¬ 
view  shown  in  Figure  III-4  is  used  at  SPCC  for  provisioning 
hull,  mechanical,  electrical  and  ordnance  components.  A  com¬ 
parison  between  this  figure  and  Figure  III-2  illustrates  the 
similarity  of  processing  interfaces  between  these  systems.  Both 
of  the  provisioning  subsystems  interface  directly  with  the  UICP 
Wholesale  Requirements  Computation  Application  and  indirectly 
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Figure  II 


with  the  UICP  SPCC  Pr o v is i on i ng / SSR  Interface  Application  and 
the  SSR  Application.  The  SPCC  HME&O  Provisioning  Subsystem  does 
not  have  an  automated  interface  with  the  UICP  Provisioning  Screen¬ 
ing  Application.  Since  all  of  the  interfacing  applications  were 
discussed  in  the  previous  subsection,  only  the  SPCC  HME&O  Provi¬ 
sioning  Subsystem  shown  in  Figure  III-4  is  discussed  here.  This 
subsystem  is  processed  on  a  provisioning  package  basis  and  is 
executed  on  a  weekly  cycle  in  a  batch  processing  mode. 

a.  Inputs  ■  Inputs  to  this  subsystem  consist  of  provi¬ 
sioning  data  from  the  contractor  or  as  determined  by  SPCC,  local 
interrogations  and  error  corrections. 

(1)  Provisioning  Data.  Card  input  containing  basic 
provisioning  item  information. 

(2)  Local  Interrogations.  Card  input  to  extract 
selected  information  from  provisioning  files. 

(3)  Error  Corrections.  Card  input  to  correct  vali¬ 
dation  errors  encountered  in  the  provisioning  data. 

b.  Files .  The  seven  files  used  by  this  subsystem  are 
the  WSF,  Local  TIR  File,  PSI  File,  TRF ,  ONR  File,  Validation 
Suspense  File  and  Computation  Suspense  File. 

( 1 )  Weapons  System  File  (WSF). 

( 2 )  Local  Total  Item  Record  (TIR)  File. 

(3 )  Program  Support  Interest  (PSI)  File. 

(4)  Technical  Reference  File  (TRF). 

(  5)  Old  NUN  Reference  (ONR)  File. 

(6)  Validation  Suspense  File.  Each  support  item 
entering  into  the  provisioning  subsystem  consists  of  several 
cards  of  data.  When  an  item  has  one  or  more  cards  with  valida¬ 
tion  errors,  the  valid  cards  are  written  to  the  Validation 
Suspense  File  on  magnetic  tape  to  await  correction  of  the  inva¬ 
lid  cards. 


(7)  Computation  Suspense  File.  This  magnetic  tape 
file  contains  data  for  items  that  have  passed  validation  and 
have  been  loaded  to  the  major  UICP  files.  They  are  awaiting 
completion  of  the  remainder  of  the  provisioning  package  so  pro¬ 
cessing  may  continue. 
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c .  Processing 


Provisioning  data  input  to  this  subsystem  is  first 
validated  for  format  and  content.  Each  item  input  consists  of 
several  cards.  When  all  cards  for  an  item  are  valid,  they  con¬ 
tinue  processing.  When  one  or  more  cards  are  found  to  be  invalid, 
the  valid  cards  are  put  on  the  Validation  Suspense  File.  Cards 
that  are  invalid  are  listed  and  skeleton  cards  are  automatically 
punched  with  the  error  fields  being  left  blank.  During  each 
processing  cycle  a  list  of  the  items  clearing  validation  is  pro¬ 
duced  as  well  as  a  listing  of  the  Validation  Suspense  File. 

When  all  cards  for  an  item  pass  validation  file 
maintenance  transactions  are  produced  to  load/update  the  UICP 
files  shown  in  Figure  III-4.  In  addition,  the  quantities  to  be 
used  as  wholesale  and  retail  requirements  in  SSR  candidates  are 
computed  at  this  time.  Item  transactions  are  then  written  to 
the  Computation  Suspense  File.  Transactions  remain  on  this  file 
until  all  support  items  in  a  provisioning  package  reach  this 
processing  point.  These  transactions  are  then  output  to  the 
Computation  Transaction  File  for  further  processing.  The  corn- 
put. tion  transaction  file  is  input  to  the  UICP  Wholesale  Require¬ 
ments  Computation  Application  for  computation  of  System  Stock 
for  SPCC  managed  items  after  which  SSR  transactions  are  generated 
for  processing  in  the  UICP  SSR  Application  by  the  UICP  SPCC  Pro- 
visioning/SSR  Interface  Application  as  discussed  above  under 
Electronics  Provisioning. 

d.  Outputs .  Outputs  from  this  application  include  the 
Validation  Error  List/Cards,  Validation  Suspense  File  List, 

Clea.ed  Items  List,  File  Update  Transactions,  and  Computation 
Transact  ions . 


(1)  Validation  Error  List/Cards.  This  is  a  list  of 
cards  found  to  be  invalid  in  this  processing  cycle  and  prepunched 
error  correction  cards. 

(2)  Validation  Suspense  File  List.  These  are  valid 
card  image  transactions  awaiting  additional  input  cards  before 
further  processing  may  take  place. 

(3)  Cleared  Items  List.  These  are  items  passing 
from  validation  processing  to  computation  processing. 

(4)  File  Update  Transactions.  These  are  transac¬ 
tions  to  update  major  UICP  files. 

(5)  Computation  Transactions.  These  are  transac¬ 
tions  forwarded  to  the  UICP  Wholesale  Requirements  Computation 
Application. 
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4.  ASO  Provisioning  System  Overview.  The  overview  of  the 
automated  provisioning  system  used  at  ASO  is  shown  in  Figure 
III-5.  This  figure  shows  that  only  the  UICP  SSR  application  is 
common  to  the  automated  systems  used  by  SPCC  and  ASO.  Since  the 
UICP  SSR  application  was  discussed  previously,  it  will  not  be 
addressed  here . 

a.  ASO  Provisioning  Subsystem.  The  ASO  Provisioning 
Subsystem  is  undergoing  extensive  revision  and  reprogramming,  so 
current  document  at  ion / i n f or ma t ion  on  this  subsystem  is  very 
limited.  As  a  result,  this  subsystem  is  discussed  only  on  a 
very  general  basis. 

(1)  Inpu  1 8  .  The  only  known  inputs  to  this  sub¬ 
system  are  provisioning  data  and  error  corrections.  It  is  noi 
known  if  this  data  is  entered  in  card  or  magnetic  tape  form. 

(2)  Files .  The  major  UICP  files  shown  in  Figure 
III-5  are  used  by  this  provisioning  subsystem.  It  is  unknown  if 
any  other  files  (suspense  files,  history  files,  etc.)  are  part 
of  this  subsystem. 

(a)  Weapons  System  File  (WSF) 

(b)  Technical  Reference  File  (TRF) 

(c)  Local  Total  Item  Record  (TIR)  File 

(d)  Program  Support  Interest  (PSI)  File 

(3)  Processing ■  The  primary  function  of  this  sub¬ 
system  is  to  load  major  ICP  files.  Additionally,  a  manual  deter¬ 
mination  is  made  in  this  subsystem  whether  requirements  computa¬ 
tions  will  be  made  manually  or  through  the  UICP  ASO  Provisioning/ 
SSR  Interface  Application.  If  requirements  are  computed  man¬ 
ually,  SSR  transactions  are  generated  by  this  subsystem;  if  re¬ 
quirements  are  computed  in  the  UICP  ASO  Pr o v i s i on i ng / SSR  Inter¬ 
face  Application,  the  SSRs  are  generated  in  that  application. 

The  Systems  Overview  Chart  (Figure  III-5)  reflects  this  pro¬ 
cessing  flow. 

(4)  Outputs  .  SSR  transactions  and  UICP  file  update 
transactions  are  the  known  outputs  of  this  subsystem. 

b ■  UICP  ASO  Provlslonlng/SSR  Interface  Application. 

This  application ,  like  the  UICP  SPCC  Provisioning /SSR  Interface 
Application,  serves  as  a  link  between  the  ASO  Provisioning  Sub¬ 
system  and  the  SSR  Application.  Processing  is  provisioning 
package  oriented  and  Is  executed  in  a  batch  processing  mode. 


AUTOMATED  SYSTEM  OVERVIEW 


Lgure  III- 


(1)  Inputs .  Inputs  to  this  application  Include  the 
Provisioning  Item  Tape,  Provisioning  Program  Data  Transfers,  and 
Provisioning  Project  App r o va 1 s / Da t a  Corrections. 


(a)  Provisioning  Item  Tape.  This  magnetic 
tape  contains  item  identifiers  of  items  to  be  processed  by  the 
interface  application. 

(b)  Provisioning  Program  Data  Transfers.  Pro¬ 
gram  data  to  be  used  by  the  interface  application  is  input  on 

E  A  M  cards. 


( c )  Provisioning  Project  Approval/Data  Correc¬ 
tions.  Project  approvals  and  corrections  are  entered  on  EAM 
cards  for  input  to  this  application. 


(2)  Files.  Generally  the  major  files  listed  are  not 
updated  by  this  application.  Data  is  extracted  from  them  for  use 
bv  this  application  resulting  in  output  of  update  transactions. 


( a )  Weapons  System  File  (WSF)  . 


(b) 

Local 

Total  Item 

Record  (TIR) 

File  . 

(c) 

Program  Support 

Interest  (PSI) 

File  . 

(d) 

Old  NUN  Record 

(ONR)  File. 

(e) 

Cross 

Reference 

File  ( CRF )  . 

(f)  Provisioning  Hold  File.  Provisioning  Pack¬ 
ages  which  require  approval  or  correction  before  they  may  con¬ 
tinue  processing  are  held  on  this  magnetic  tape  file. 

(3)  Processing.  Processing  in  this  interface  appli¬ 
cation  differs  significantly  from  the  one  used  by  SPCC.  This 
interface  application  accesses  sophisticated  computer  models  to 
compute  initial  outfitting  and  system  stock  quantities  after 
necessary  data  has  been  extracted  from  the  major  ICP  files  and 
validated. j  These  models  are  used  to  compute  wholesale  and  retail 
SSR  quantities  when  they  are  included  in  the  provisioning  package. 
After  quantitative  requirements  are  computed,  output  products 
are  produced  including  SSR  transactions.  Before  SSR  transac¬ 
tions  are  generated,  the  SSR  candidate  items  must  meet  certain 
criteria  prescribed  by  ASO.  First  the  item  must  be  source  coded 
in  the  "P"  series.  Then,  if  the  item  has  an  NSN  assigned,  ASO  is 
not  registered  as  a  user,  and  computed  quantities  are  greater 
than  zero,  an  SSR  is  generated.  If  the  item  has  no  NSN  assigned 
(part  numbered  item),  and  the  retail  or  replenishment  quantity 
is  greater  than  zero,  an  SSR  is  also  generated.  The  SSR  trans¬ 
actions  generated  are  processed  in  the  SSR  application  discussed 
above  . 
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(4)  Outputs  ■  The  outputs  generated  by  this  appli¬ 
cation  include  Provisioning  Monitoring  transactions,  File  Mainte¬ 
nance  transactions,  Modified  Purchase  transactions,  Planned 
Requirements  transactions,  SSR  transactions  and  Functional  Re¬ 
ports/Listings. 


( a )  Provisioning  Monitoring  Transactions. 

These  are  transactions  to  update  project  status  in  the  Automated 
Provisioning  Monitoring  Application. 

(b)  File  Maintenance  Transactions.  Transac¬ 
tions  to  update  major  ICP  files. 

( c )  Modified  Purchase  Transactions. 

( d )  Planned  Requirements  Transactions  . 

(e)  SSR  Transactions.  Transactions  to  be  pro¬ 
cessed  by  the  SSR  Application. 

(f)  Functional  Outputs.  These  are  hard  copy 
r e por t s / 1 i s t i n g s  used  for  functional  processing. 

E.  DETAILED  UICP  SSR  APPLICATION  DESCRIPTION 


During  the  design  of  this  application,  it  was  decided  to  split 
the  application  into  two  phases.  Phase  I  would  handle  Outgoing 
SSR  processing,  while  Phase  II  would  handle  Incoming  SSR  processing. 
The  reason  for  dividing  the  application  into  two  phases  was  the 
relatively  high  number  of  outgoing  transactions  processed  compared 
to  the  relatively  low  number  of  incoming  transactions  processed. 
Primary  emphasis  from  the  using  ICPs  because  of  these  relative 
volumes  was  on  the  outgoing  processing  portion.  Also  it  was  felt 
that  while  the  total  application  could  not  be  completed  in  time 
for  concurrent  implementation  with  the  new  IMM  Manual  (Appendix 
D,  Reference  9),  the  outgoing  SSR  processing  portion  could  be 
completed  in  time.  As  a  result,  the  application  was  split  into 
these  two  phases  with  each  phase  having  separate  inputs,  outputs, 
files,  processing  criteria,  and  program  streams.  Each  phase  will 
be  discussed  and  displayed  separately  as  designed. 

1 .  UICP  SICC  SSR  Application  (Phase  I) 


This  phase  handles  all  SICC  SSR  processing  including 
validation,  file  maintenance  of  the  SICC  SSR  Suspense  File, 
generation  of  tollowup  transactions,  and  generation  of  file 
update  transactions.  As  illustrated  in  Figure  III-6,  Phase  I 
consists  of  five  program  modules.  These  modules  are  the  PDR 
update,  SSR  Validation,  SSR  File  Maintenance,  SSR  Form  Letter 
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Generator  and  SSR  Inqu 1 r y / Re por t  Generator.  Two  of  these  pro¬ 
gram  modules  (PDR  Update  and  Form  Letter  Generator)  are  con¬ 
sidered  to  be  optional  for  implementation.  These  two  modules 
have  been  implemented  by  ASO ;  however,  the  intention  of  SPCC  was 
not  to  implement  these  program  modules.  Processing  is  done  on 
an  LISSR  package  basis  and  is  done  in  a  batched  sequential  mode. 
Phase  I  is  recommended  to  be  scheduled  on  a  weekly  basis  and 
scheduling  is  done  on  a  program  module  by  program  module  basis 
rather  than  in  a  single  job  stream. 

The  procedures  in  the  current  I  MM  Manual  call  for  a 
specific  format  for  SSR  transactions  submitted  for  NSN  items 
actively  managed  by  an  IMM.  SSR  transactions  submitted  for  NSN 
items  not  actively  managed  by  an  IMM  are  essentially  in  the  same 
format,  but  have  additional  data  elements  required.  These  include 
Source  Code,  Demilitarization  Code,  Procurement  Method  Code,  Shelf 
Life  Code,  Production  Leadtime  and  Unit  Price  for  items  submitted 
to  a  CIMM.  When  an  SSR  transaction  for  an  NSN  item  is  input  to 
Phase  I,  the  validation  program  module  examines  the  transaction 
for  these  data  elements.  If  the  Source  Code,  Demilitarization 
Code,  Procurement  Method  Code,  Shelf  Life  Code  and/or  Production 
Leadtime  are  not  present  in  the  transaction,  a  default  value  will 
be  entered  into  the  transaction;  however,  if  the  Unit  Price  is 
absent,  the  transaction  will  be  rejected. 

a.  PDR  Update .  This  program  module  updates  the  PDR 
File  with  Program  Data  Header  and  PDR  Supplementary  Transactions. 
This  program  module  is  optional  for  implementation. 

(1)  Inputs.  The  only  input  to  this  program  module 
is  the  PDR  update  transactions  shown  in  Figure  III-6.  These 
transactions  are  manually  generated  and  may  add,  change,  or 
delete  records  on  the  PDR  File. 

(2)  Files .  The  Program  Data  Record  (PDR)  File  is 
the  single  file  accessed  by  this  program  module.  Changes  to 
this  magnetic  tape  file  are  made  through  the  use  of  PDR  update 
transactions  only.  The  file  consists  of  PDSSR  transactions 
(less  ACT  and  ACF )  and  PDR  Supplementary  Transactions  in  PCC  and 
Card  Number  (cc  6)  sequence.  Only  the  PDR  Supplementary  Trans¬ 
actions  contain  a  card  number  ("2")  and  only  one  is  allowed  for 
a  matching  PDSSR  transaction.  These  PDR  Supplementary  Trans¬ 
actions  contain  data  for  local  ICP  use  only  and  are  not  dissemi¬ 
nated  to  other  activities.  The  transactions  added  to  the  file 
are  essentially  a  card  image  of  the  PDR  update  transactions 
input.  Both  PDSSR  transactions  for  initial  submission  and  PDSSR 
transactions  for  submission  of  changes  to  previously  submitted 
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SSR  transactions  reside  on  the  PDR  File.  The  Activity  Code  To 
and  Activity  Code  From  are  added  when  the  PDSSR  is  extracted 
from  the  PDR  file  based  on  the  codes  in  the  LISSR  transactions 
it  is  to  accompany. 

(3)  Processing .  Input  transactions  are  first  sorted 
to  match  the  PDR  file  sequence  and  validated  for  format  and  con¬ 
tent.  Invalid  transactions  are  written  to  the  Invalid  Update 
Transaction  File  which  later  is  used  to  produce  cards  for  manual 
correction  and  reentry  to  this  program  module.  Valid  records 
update  the  PDR  File. 

(A)  Outputs  .  Invalid  update  transactions  are  out¬ 
put  to  tape  which  are  later  transferred  into  punched  cards  for 
manual  correction. 

b.  S1CC  SSR  Validation.  This  program  module  validates 
outgoing  SSR  transactions,  LIACs  and  manually  generated  input 
transactions  . 

(1)  Inputs  .  Inputs  to  this  program  module  include 
SSR  transactions  generated  on  an  automated  basis  and  manually 
generated  inputs. 

(a)  SSR  transactions  from  the  UICP/SPCC  Provi- 
sioning/SSR  Interface  Application. 

(b)  SSR  transactions  from  the  UICP/ASO  Provi- 
sioning/SSR  Subsystem. 

(c)  SSR  transactions  from  the  UICP/ASO  Provi- 
sioning/SSR  Interface  Application. 

(d)  Manual  Input  includes  manually  generated 
provisioning  and  nonprovisioning  SSR  transactions,  corrected  SSR 
transactions  previously  rejected  by  this  program  module,  advice 
transactions  from  IMMs,  SICC  SSR  Suspense  File  maintenance  trans¬ 
actions  and  change  SSR  transactions. 

(2)  Files .  The  Program  Data  Record  (PDR)  file  Is 
accessed  by  this  program  module. 

(3)  Processing.  This  is  basically  a  validation 
program  module.  All  Inputs  are  first  sorted  together  into  PCC, 
ACT,  ISN,  DOR,  DIC,  and  Card  Number  sequence.  Then  each  trans¬ 
action  undergoes  detail  data  element  validation  for  format  and 
content.  Specific  validation  criteria  is  discussed  in  Volume 
III.  Transactions  found  to  be  in  error  are  appended  with  a  Navy 
unique  reject  code  before  being  output  for  manual  correction. 

All  data  elements  are  validated  with  a  reject  code  of  "V"  being 


used  for  those  transactions  found  with  multiple  errors.  Data 
elements  found  in  error  are  filled  with  blanks.  Valid  LISSR 
transactions  are  checked  for  an  associated  PDSSR  transaction. 

If  a  PDSSR  is  not  found,  the  PDR  file  is  checked  for  a  PDSSR 
transaction,  and  if  one  is  found,  it  is  extracted  from  this 
file.  If  no  valid  PDSSR  transaction  is  present  and  one  cannot 
be  located  on  the  PDR  file,  a  dummy  PDSSR  transaction  which  must 
be  completed  manually  before  the  SSR  package  is  mailed  to  the 
I  MM  is  created  to  accompany  the  LISSR  transactions.  All  trans¬ 
actions  entered  into  this  process  are  output  to  the  SICC  SSR 
Transaction  File. 

(4)  Output.  The  SICC  SSR  Transaction  File  is  the 
only  output  from  this  program  module.  It  contains  all  transac¬ 
tions  input  to  the  program  module  with  the  addition  of  PDSSR 
transactions  generated  or  extracted  from  the  PDR  file. 

c.  SICC  SSR  File  Maintenance.  This  program  module 
establishes,  updates  and  deletes  records  from  the  SICC  SSR 
Suspense  File.  It  also  determines  the  need  for  generation  of 
followup  actions  on  existing  records. 

(1)  Inputs.  The  only  input  to  this  program  module 
is  the  SICC  SSR  Transaction  File  from  the  previous  program 
module  . 

( 2 )  Files 


The  SICC  SSR  Suspense  File  is  the  only  file 
accessed  by  this  program  module.  This  magnetic  tape  file  is  an 
active,  suspense  and  history  file  and  is  sequenced  on  PCC,  ACT, 
ISN,  DOR,  Transaction  Date,  DIC,  and  Card  Number.  Transactions 
found  to  be  invalid  in  the  validation  program  module  are  not 
posted  to  this  file.  Valid  SSR  transactions  are  expanded  from 
the  standard  80  card  column  format  to  a  100  character  record 
length  before  being  entered  in  the  SICC  SSR  Suspense  File.  The 
first  80  positions  of  the  100  character  record  is  essentially  a 
card  image  of  the  input  transaction.  The  remaining  20  positions 
allow  for  entry  of  data  for  local  ICP  use.  Positions  81  through 
84  contain  a  transaction  or  process  date  which  is  the  date  the 
transaction  entered  the  SICC  SSR  Suspense  File.  Data  in  posi¬ 
tions  85  thru  100  is  dependent  on  the  type  of  transaction. 

PDSSR  transaction  records  contain  a  count  of 
the  Number  of  Open  LISSR  transactions  (those  not  complete  in  the 
PCC  package)  in  positions  85-88;  the  remainder  of  the  record  is 
blank.  The  PDR  Supplementary  Data  transaction  record  is  blank 
in  positions  85-100.  LISSR  transaction  records  containing  an 
NSN  or  PSCN  contain  a  current  status  code  (awaiting  IMM  action, 
awaiting  internal  ICP  action,  complete)  in  position  85  and  the 
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completion  date  in  positions  86-89;  the  remainder  of  this  type 
record  is  blank.  LISSR  transaction  records  for  part  number  items 
consist  of  two  record  combinations  just  as  there  are  two  trans¬ 
action  combinations  for  these  LISSR  transactions.  The  first 
record  of  the  combination  contains  the  current  status  code  in 
position  85  and  the  completion  date  in  positions  86-89  with  the 
remainder  of  the  record  blank;  positions  85-100  of  the  second 
record  in  the  combination  is  blank.  SICC  SSR  Suspense  File 
Records  for  Item  Name  transactions,  Additional  Reference  trans¬ 
actions,  Additional  User  transactions.  Offer  Reply  transactions. 
Followup  transactions,  Followup  Response  transactions,  and  Inter¬ 
nal  File  Maintenance  transactions  contain  blanks  in  positions 
85-100.  Advice  transaction  records  may  contain  a  report  indica¬ 
tor  in  position  85  with  positions  86-100  being  blank.  All  records 
found  to  be  valid  by  the  SSR  Validation  program  module  are  entered 
in  the  SICC  SSR  Suspense  File  are  and  include: 

(a)  PDSSR  Transactions 

(b)  Supplementary  PDR  Transactions 

(  c  )  LISSR  Transactions 

(d)  Item  Name  Transactions 

(e)  Additional  Reference  Transactions 

(f)  Additional  User  Transactions 

(g)  Advice  Transactions 

(h)  Offer  Reply  Transactions 

(1)  Followup  Transactions 

(j)  Followup  Response  Transactions 

(k)  Internal  ICP  File  Maintenance  Transactions 

(3)  Processing.  There  are  five  types  of  records 
input  to  this  program  module  -  valid  outgoing  SSR  transactions, 
invalid  outgoing  SSR  transactions,  LIAC  transactions,  Internal 
file  maintenance  transactions  to  act  on  the  SICC  SSR  Suspense 
File,  and  internal  file  maintenance  transactions  to  generate 
offer  replies  to  an  IMM.  Each  of  these  types  will  be  discussed 
in  turn. 

(a)  Valid  Outgoing  SSR  Transactions.  Each 


valid  outgoing  SSR  transaction  (initial  submission  or  change 
submission)  is  assigned  a  DOR  based  on  the  processing  date  plus 


14  days.  These  transactions  are  posted  to  the  SICC  SSR  Suspense 
File  and  are  output  to  the  Re por t / S t a 1 1 s 1 1 c a  1  Records  and  SSR 
card  files.  If  the  SSR  transaction  contains  a  part  number,  the 
Document  Availability  Code  (DAC)  is  ”5”  (drawing  exists,  but  not 
available);  and  the  Technical  Data  Justification  Code  (TDJC)  is 
"X"  (justification  enclosed  separately);  a  Form  Letter  Record  is 
also  output. 


(b)  Invalid  Outgoing  SSR  Transactions.  Invalid 
SSR  transactions  are  not  posted  to  the  SICC  SSR  Suspense  F-tle. 
These  SSRs  are  output  as  invalid  trarsactions  with  the  data  ele¬ 
ment  in  error  set  to  blanks  and  with  an  internal  Navy  error  code 
in  card  column  67. 

( c )  Line  Item  Advice  Card  (LIAC)  Transaction s 
from  IMMs  are  processed  based  on  the  Action  Taken  Code  (ATC) 
received  which  the  Navy  has  grouped  into  four  categories  -  Accept, 
Reject,  Offer,  and  Other. 

1  Accept  Ad v i c e .  When  an  Accept  Advice 
is  received,  the  transaction  is  posted  to  the  SICC  SSR  Suspense 
File.  When  the  LISSR  transaction  contained  an  NSN,  the  record 
is  considered  complete.  When  the  LISSR  transaction  did  not  con¬ 
tain  an  NSN,  but  the  LIAC  transactions  does  contain  an  NSN;  an 
NSN  update  transaction  is  generated  and  output  as  shown  in 
Figure  III-6.  The  SICC  SSR  Suspense  File  record  is  considered 
to  be  complete  at  this  point.  When  the  LISSR  transaction  did 
not  contain  an  NSN  and  the  LIAC  transaction  does  not  contain  an 
NSN,  the  record  is  held  open  awaiting  an  additional  LIAC  trans¬ 
action  containing  the  required  NSN.  When  the  advice  code  is 
"YD"  (support  ac ce p t ed -non s t ocked  item),  a  record  will  be  gener¬ 
ated  for  the  AAC  "J"  Item  Review  List.  This  list  contains  items 
which  will  not  be  purchased  by  the  I  MM  until  a  funded  requisi¬ 
tion  is  received.  A  sample  format  for  this  list  is  given  in 
Figure  1 1  I  —  7  .  When  the  advice  code  is  "YX"  (support  accepted  - 
new  support  date),  a  record  is  generated  for  the  YX  Item  Review 
List.  This  list  contains  items  for  which  the  I  MM  cannot  meet 
the  Date  Repair  Parts  Required  submitted  in  the  PDSSR  transac¬ 
tion.  An  alternate  support  date  is  given  In  the  LIAC  transac¬ 
tion.  The  format  for  this  list  is  shown  in  Figure  III-8. 

2^  Reject  Advice.  When  a  reject  advice 
is  received,  it  is  posted  to  the  SICC  SSR  Suspense  File.  The 
reject  LIAC  transaction  and  all  other  transactions  on  the  SICC 
SSR  Suspense  File  which  match  on  PCC,  ACT,  ISN,  and  DOR  are  out¬ 
put  to  the  Report/Statistical  Records  file  and  are  output  as 
Manual  Review  Transactions. 
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AAC  “J"  ITEM  ACTION  LIST 


Date  XXXXX 


The  I  MM  replied  to  the  following  Supply  Support  Requests 
from  this  activity  with  Action  Taken  Code  "YD.”  A  funded  docu¬ 
ment  (MILSTRIP  or  MIPR)  must  be  submitted  to  the  I  MM  no  later 
than  180  days  prior  to  the  date  the  item  is  required. 


Ml  IN / AC N 

PCC 

Activity 

Code 

To 

ISN 

Retail 

Quantity 

Wholesale 

Quantity 

Date  Re  pa i 

Parts 

Required 

XXXXXXXXX 

XXX 

XX 

XXXXXX 

XXXXX 

XXXXX 

xxxx 

NOTE:  Items  will  be  omitted  from  this  list  when  both  quantity 

fields  equal  zero. 


Figure  1 1 1 - 7 


ACTION  TAKEN  CODE  "YX"  LIST 

The  I  MM  replied  to  the  following  Supply  Support  Requests 
from  this  activity  with  Action  Taken  Code  "YX"  (procurement 
action  initiated  by  IMM  -  Item  will  be  supported  by  date  indi¬ 
cated).  If  the  new  support  date  is  not  acceptable  to  meet 
initial  critical  requirements,  this  ICP  may  procure  the  quantity 
needed  prior  to  the  new  support  date. 


N  I  I  N  /  A  C  N 

PCC 

Activity 

Code 

To 

ISN 

Retail 

Quantity 

Wholesale 

Quantity 

New 

Support 

Date 

XXXXXXXXX 

XXX 

XX 

XXXXXX 

XXXXX 

XXXXX 

XXXX 

NOTE:  Items  will  be  omitted  from  this  list  when  both  quantity 

fields  equal  zero. 


3^  Offer  Advice.  When  an  offer  advice 
is  received,  the  transaction  is  posted  to  the  SICC  SSR  Suspense 
File.  A  transaction  identical  to  the  LIAC  transaction  except 
the  DIC  will  be  CXY,  is  output  as  a  manual  review  transaction. 

SSR  transactions  matching  this  LIAC  on  PCC,  ACT,  ISN,  and  DOR 
will  be  output  through  the  Re por t  /  S t a t i s t i c a  1  Records  File. 

4^  Other  Advice  .  Three  of  the  ATCs  from 
the  IMM  Manual  fall  into  this  category  (64,  66,  67).  When  an 

advice  transaction  containing  ATC  "64"  (procurement  delayed  pend¬ 
ing  receipt  of  adequate  technical  data)  is  received,  it  is  posted 
to  the  SICC  SSR  Suspense  File  and  output  along  with  original  SSR 
data  to  the  functional  user  for  manual  review.  An  advice  trans¬ 
action  containing  ATC  "67"  (advice  pending)  is  simply  posted  to 
the  SICC  SSR  Suspense  File.  An  ATC  of  "66”  (no  record)  is  re¬ 
ceived  only  on  fol lo wup  response  transactions  and  when  received 
is  posted  to  the  SICC  SSR  Suspense  File.  In  addition,  new  SSR 
t  ransactlons  are  automatically  generated  for  mailing  to  the  IMM 
when  this  ATC  is  received. 

( d )  Internal  File  Maintenance  Transactions  . 
Internal  file  maintenance  transactions  to  act  on  the  SICC  SSR 
Suspense  File  are  transactions  to  deal  with  SSRs  which  received 
reject  advice  from  the  IMM.  This  application  allows  for  four 
basic  actions  to  take  care  of  rejected  SSR  transactions.  First, 
an  internal  file  maintenance  transaction  with  DIC  equal  to  CXX 
and  containing  the  PCC,  ACT,  and  ISN  of  the  rejected  SSR  item 
may  be  input.  This  transaction  in  effect  will  cancel  the  SSR 
and  complete  the  SICC  SSR  Suspense  File  Record.  Second,  an 
internal  file  maintenance  transaction  with  DIC  equal  to  CXX  and 
containing  the  PCC,  ACT,  ISN,  and  DOR  of  the  rejected  SSR  item 
and  also  containing  an  NSN  may  be  input.  This  transaction  will 
enter  the  NSN  in  the  Sr1,  complete  the  SICC  SSR  Suspense  File 
record  and  generate  an  ..'SN  update  transaction.  Third,  when 
changes  are  required  to  data  elements  other  than  the  DIC,  NSN/ 
FSCM  Part  Number/PSCN,  PCC,  ACT,  ISN  or  DOR,  the  change  transac¬ 
tions  mav  be  input  with  a  ”C"  in  card  column  67.  This  action 
results  in  a  resubmittal  of  the  SSR  with  a  new  DOR  and  an  ad¬ 
justed  Date  Repair  Parts  Required  and  End  Item  Delivery  Code 
when  required.  These  transactions  are  output  the  same  as  any 
other  new  SSR  submitted  for  the  first  time;  however,  both  the 
new  SSR  transactions  and  the  previous  SSR  transactions  reside  on 
the  SICC  SSR  Suspense  File.  Finally,  when  extensive  changes  are 
needed,  a  new  SSR  transaction  must  be  manually  generated  and 
entered  into  the  application.  Placing  an  "R”  in  card  column  67 
of  the  new  SSR  transactions  will  allow  previous  transactions  to 
remain  on  the  SICC  SSR  Suspense  File  as  an  audit  trail  except 
for  changes  to  ACT.  This  type  of  change  requires  a  cancellation 
transaction  to  complete  the  SICC  SSR  Suspense  File  Record  to  be 
submitted  concurrently  with  the  new  SSR  transactions. 
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(e  )  Generation  of  File  Maintenance  Transactions. 
The  CXY  transaction  created  as  a  result  of  an  offer  may  be  used 
to  generate  a  reply  to  the  offer.  This  Is  done  by  entering  a 
code  in  card  column  67  of  the  CXY  transation.  When  the  code 
entered  is  "M"  or  "P,"  an  offer  reply  transaction  will  be  gener¬ 
ated  with  an  ATC  to  accept  the  offer  and  the  SICC  SSR  Suspense 
File  Record  will  be  considered  complete.  When  the  code  entered 
is  “N"  or  "V,"  an  Offer  Reply  Transaction  will  be  generated  with 
an  ATC  to  reject  the  offer.  In  this  case  the  SICC  SSR  Suspense 
File  Record  remains  open  pending  receipt  of  a  LIAC  transaction 
containing  the  required  NSN. 

(f)  File  Surveillance.  There  are  three  external 
and  internal  processes  accomplished  by  this  program  module.  These 
are  followup  generation,  and  SICC  SSR  Suspense  File  purge  proce¬ 
dures.  These  processes  are  done  after  all  incoming  transactions 
have  been  processed. 

1  External  Followups 

Followups  are  generated  on  an  external 
and  internal  basis.  External  followups  are  generated  based  on 
the  following  criteria: 


a  Initial  advice  has  not  been  received 
from  the  IMM  within  35  days  from  the  DOR. 

b  Initial  advice  of  action  pending  has 
not  been  followed  with  final  advice  within  25  days. 

£  An  NSN  has  not  been  received  for  an 
SSR  submitted  with  a  Part  Number/PSCN  within  70  days  from  the 
DOR  . 


d_  An  NSN  has  not  been  received  within 
70  days  from  the  transmittal  of  an  offer  reply  transaction 
rejecting  an  offer. 

If  a  response  is  not  received  for  a  followup  generated  for  any 
of  the  above  criteria,  another  followup  is  generated  25  days 
after  the  first  followup  was  created.  All  of  these  followup 
transactions  are  output  as  cards  as  reflected  in  Figure  III-6. 

2_  Internal  Followups 


Internal  followups  are  generated  on  the 
basis  of  the  following  criteria: 

£  A  response  to  an  offer  from  the  IMM 
not  being  processed  within  AO  days  after  receipt  of  the  offer. 
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b  Action  not  being  taken  on  a  reject 
from  the  IMM  within  45  days  after  receipt  of  the  reject  trans¬ 
action. 


£  Correction  to  a  dummy  PDSSR  transac¬ 
tion  generated  in  the  validation  program  module  not  made  within 
15  days  of  creation. 

Internal  followups  take  the  form  of  file  data  for  an  item  with  a 
reason  for  followup  message  and  are  output  to  the  reject/statis¬ 
tical  record  file  for  printing. 

3^  SICC  SSR  File  Purge.  There  are  several 
actions  that  complete  LISSR  transaction  packages  on  the  SICC  SSR 
Suspense  File  which  were  discussed  above.  After  completion, 
these  packages  remain  on  the  SICC  SSR  Status  File  for  180  days. 
When  this  time  has  expired,  the  package  is  purged  from  the  file. 
Note  that  purging  is  on  a  LISSR  transaction  package  basis,  not 
on  a  PCC  package  basis. 

( 4 )  Outputs 


(a)  Re po r t / S t a t i s t i c a  1  Records.  These  are 
records  which  are  output  concurrently  with  local  inquiry  outputs. 

(b)  NSN  Update  Tr a n s ac t i o n s / L i s t  .  These  are 
update  transactions  forwarded  to  the  file  maintenance  applica¬ 
tion  which  updates  the  local  TIR,  PSI  and  TRF  files. 

(c)  YX  Item  Review  List.  This  is  a  listing 
of  those  items  accepted  for  support  by  the  IMM,  but  the  IMM 
cannot  furnish  support  by  the  Date  Repair  Parts  Required.  An 
alternate  support  date  is  supplied  in  the  LIAC  transaction  and 
shown  on  the  list.  See  Figure  III-7. 

(d)  AAC  "J"  Item  Review  List.  This  is  a  list 
of  those  items  accepted  for  support  by  the  IMM,  but  will  not  be 
purchased  until  receipt  of  a  requisition.  See  Figure  III-7. 

(e)  Form  Letter  Records.  These  are  transac¬ 
tions  used  to  produce  form  letters  to  suppliers  in  a  program 
module  discussed  below. 

( f )  SSR  Cards/Offer  Reply  Cards/Followup  Trans¬ 
actions  .  These  are  punched  cards  output  in  ACT,  PCC,  ISN,  DOR, 
DIC,  and  Card  Number  sequence  for  transmittal  to  one  or  more 
IMMs.  SSR  transactions  are  outgoing  SSR  transactions  including 
initial  submittals,  re s ubm 1 1 1 a  1 s  ,  or  change  submitals.  Offer 
Reply  transactions  inform  the  IMM  of  acceptance  or  rejection  or 
an  offered  item.  These  followup  transactions  are  to  be  submitted 
to  an  IMM  (external  followups).  Outgoing  SSR  transactions  are 
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mailed  to  the  IMM  by  the  functional  user.  Offer  reply  and  fol¬ 
lowup  transactions  may  be  either  mailed  or  transmitted  via 
AUTODIN  to  the  IMM;  the  choice  is  left  to  the  functional  user. 

( g )  Manual  Review  Tramiactlons  .  These  are 
cards  output  for  manual  review  in  conjunction  with  lists  from 
the  Inquiry/Report  Generator  program  module.  They  consist  of 
outgoing  SSR  transactions  rejected  by  the  IMM  and  CXY  transac- 
t ions  . 


(h)  Invalid  Transactions.  These  are  outgoing 
SSR  transactions  which  were  found  to  be  in  error  by  the  Validation 
Program  Module.  The  data  element  in  error  appears  as  blank  on  the 
card  and  the  internal  error  code  is  in  card  column  67. 

d.  Form  Letter  Generator.  This  program  module  produces 
form  letters  requesting  technical  data  from  the  manufacturer. 

This  program  module  is  optional  for  implementation. 

(1)  Input.  Input  to  this  program  module  are  the 
form  letter  records  produced  by  the  SICC  SSR  file  maintenance 
program  module. 

(2)  Files  .  The  Supplier's  Data  File  is  accessed  by 
this  program  module  to  extract  manufacturers  names  and  addresses 
for  the  form  letters.  This  is  a  sequential  magnetic  tape  file 
with  information  extracted  based  on  FSCM. 

(3)  Processing .  Input  records  are  first  sorted 
into  FSCM,  ACT,  PCC,  and  ISN  sequence.  They  are  then  processed 
against  the  Supplier's  Data  file  to  pick  up  the  manufacturer's 
address.  An  internal  table  is  used  to  get  the  address  of  the 
Activity  Code  To.  These  addresses  along  with  other  input  data 
are  used  to  generate  the  form  letters  a  sample  ot  which  is  shown 
in  Figure  III-9.  Note  that  the  form  letter  requests  that  tech¬ 
nical  data  be  sent  directly  to  the  IMM. 

(4)  Output  .  Technical  data  omission  letters. 

e.  Inqul r y / Re po r t  Generator.  This  program  module  pro¬ 
cesses  inquiry  transactions,  produces  prints  of  SICC  SSR  Suspense 
File  records,  and  produces  statistical  reports. 

( 1 )  Inputs 


(a)  SICC  Inquiry  Transactions.  These  transac¬ 
tions  request  an  extract  and  print  of  records  residing  on  the 
SICC  SSR  Suspense  File  for  functional  use. 
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Department  of  the  Navy 
Aviation  Supply  Office 
700  Robbins  Avenue 

In  reply  refer  to: 
DAS  3 -A 

October  05,  1976 

To  Lockheed-Ca 1 i f or nia  Co.  36659 
ATTN:  MGR.  D6412 

Build  167  Plant  A1 
P . 0 .  Box  551 
Burbank,  Cal.  91503 

Gentlemen: 

1.  It  is  requested  that  documentation,  dr  a win g s / ca t a  1 og 
pages  for  the  items  listed  below  be  annotated  with  the 
Applicable  Provisioning  Control  Code  (PCC)  and  Item  Serial 
Number  (ISN)  and  forwarded  directly  to  the  addressee  shown  in 
paragraph  3. 

2.  When  the  supporting  technical  data  (complete  description) 
are  contained  in  a  commercial  catalog  available  to  the 
general  public,  the  originator  may  satisfy  requirements  for 
data  by  sending  either  a  facsimile  of  the  actual  description 
or  by  a  separate  technical  data  sheet  giving  name  and  FSCM  of 
the  company  publishing  the  catalog,  catalog  issue  number  or 
equipment  name/type  designator  catalog  date  and  catalog  page 
numers  which  include  the  description  of  the  item. 

3.  Addressee 
COMMANDER 

Defense  Construction  Svpply  Ctr  AX 

ATTN:  DCSC-SP2 

Columbus,  Ohio  43215 

P=FSCM  Primary  Part  Number  S=FSCM  Secondary  Part  Number 

10929  2023  5A6-40W  PCC  ISN  END  ITEM  NSN  ACT  TO 

QA2  V 1 1 6  S  3 A  AX 


Sincerely 


Branch  Head 

Data  Acquisition  and  Support 


Figure  I I I -9 
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(b)  Re po r t / S t a t 1 s t 1 ca 1  Records.  These  are 
records  generated  by  the  File  Maintenance  Program  Module. 

(2)  Files  .  The  SICC  SSR  Suspense  File  is  accessed 
by  this  program  module. 

(3)  Processing .  This  program  module  allows  for 
five  different  inquiry  capabilities.  An  inquiry  may  request  a 
match  on  PCC ,  ACT,  and  ISN.  Another  possibility  is  a  match  on 
PCC  only  or  a  request  for  open  records  only  within  pCC  may  be 
input.  A  fourth  capability  is  a  match  on  PCC  and  ACT  and  finally 
a  request  for  open  records  only  in  a  PCC  and  ACT  may  be  input. 

In  addition  to  inquiry  results,  SICC  SSR  Suspense  File  records 
to  be  printed  as  a  result  of  an  internal  followup  are  output  on 
the  Individual  SSR  List.  At  ASO  the  Consolidated  SSR  List  is  a 
complete  file  printout  of  the  SICC  SSR  Suspense  File.  At  SPCC, 
this  list  consists  of  SSR  transactions  which  were  resubmitted  to 
the  IMM  this  cycle,  reject  or  offer  advice  received  from  the  IMM 
this  cycle,  were  submitted  to  the  IMM  after  initial  rejection, 
or  had  an  offer  reply  transaction  submitted  to  the  IMM  this  cycle 
In  addition  various  statistical  reports  are  generated  in  the  for¬ 
mats  of  which  are  shown  in  Figures  III-10  through  III-14. 

( 4 )  Outputs 

(a)  Consolidated  SSR  List.  Printout  of  SICC 
SSR  Suspense  File  records. 

(b)  Individual  SSR  List.  Selective  printout 
of  SICC  SSR  Suspense  File  records. 

( c )  Statistical  Reports 

1_  Number  of  Outgoing  SSRs  Produced  (Figure 
I I I- 1 0 ) .  This  report  shows  the  number  of  SSR  transactions  sub¬ 
mitted  by  IMM  (ACT-TO)  in  the  processing  cycle. 

NUMBER  OF  OUTGOING  SSRs  PRODUCED 


Date  XXXXX 


ACT-To 

Total 

SSRs 

Submi t  ted 

Condition 

1 

Condi t ion 

2 

Condition 

3 

Cond it  ion 

3 

DAC  5 

XX 

XXXX 

XXXX 

XXXX 

XXXX 

XXXX 

XX 

XXXX 

XXXX 

XXXX 

XXXX 

XXXX 

XX 

XXXX 

XXXX 

XXXX 

XXXX 

XXXX 

XX 

XXXX 

XXXX 

XXXX 

XXXX 

XXXX 

Totals 

XXXX 

XXXX 

XXXX 

XXXX 

XXXX 

Figure  III-10 
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2_  Number  of  Outgoing  SSRs  Produced  by  PCC 
(Figure  III-ll).  This  report  shows  the  number  of  SSR  transac¬ 
tions  submitted  by  IMM  (ACT-TO)  within  PCC  in  the  processing 
cycle . 

NUMBER  OF  OUTGOING  SSRs  PRODUCED  BY  PCC 


Date  XXXXX 


Total  Condition 

Cond i t ion 

Condition 

Cond i t ion 

ACT- 

SSRs 

1 

2 

3 

3 

PCC 

To 

Submitted 

DAC  5 

XXX 

XX 

XXXX 

XXXX 

XXXX 

XXXX 

XXXX 

XX 

xxxx 

XXXX 

XXXX 

XXXX 

XXXX 

XX 

XXXX 

xxxx 

xxxx 

xxxx 

XXXX 

XXX 

XX 

XXXX 

xxxx 

xxxx 

xxxx 

XXXX 

XX 

XXXX 

xxxx 

xxxx 

xxxx 

xxxx 

XXX 

XX 

XXXX 

xxxx 

xxxx 

xxxx 

xxxx 

XXX 

XX 

XXXX 

xxxx 

xxxx 

xxxx 

xxxx 

XXX 

XX 

xxxx 

xxxx 

xxxx 

xxxx 

xxxx 

XX 

xxxx 

xxxx 

xxxx 

xxxx 

xxxx 

XX 

xxxx 

xxxx 

xxxx 

xxxx 

xxxx 

Totals 

XXXXX 

XXXXX 

XXXXX 

XXXXX 

XXXXX 

Figure 

III-ll 

3 

Current 

Status  Statistics  by  PCC  for 

Outg 

oing  SSRs  (Figure  III-12)  This  report 

shows  by 

PCC  the 

total  items 

in  the  PCC 

package , 

the  number 

of  items 

complete  , 

and 

the  number  of  items 

incomplete  by  time 

category 

as  of  the 

processing 

cycle  . 

CURRENT  STATUS  STATISTICS  BY  PCC 
FOR  OUTGOING  SSRs 


Date  XXXXX 


PCC 

Total 

I  terns 

Items 

Complete 

0-35 

Days 

Item  Open 

36-7C  71-120 

Days  Days 

121  Days 
or  more 

XXX 

XXXX 

XXXX 

XXX 

XXX 

xxxx 

XXXX 

XXX 

XXX 

xxxx 

XXXX 

XXX 

XXX 

xxxx 

XXXX 

XXX 

xxxx 

xxxx 

XXX 

Totals 

XXXXX 

XXXXX 

XXXXX 

XXXXX 

XXXXX 

XXXXX 

Figure  1 1 1-  12 
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4_  Number  of  SSR  Advice  Cards  Received 
(Figure  III-13).  This  report  shows  the  number  of  advice  cards 
received  by  managing  activity  within  ATC  in  the  processing  cycle 

NUMBER  SSR  ADVICE  CARDS  RECEIVED 

Date  XXXXX 

MANAGING  ACTIVITIES 


Action 

Taken 

Codes 

AX 

CX 

DX 

TX 

AZ  KZ 

75  WIMMs  Total 

YA 

XXX 

XXX 

XXX 

XXX 

XXX  XXX 

XXX  XXX 

XXXXX 

YB 

XXX 

XXX 

XXX 

XXX 

XXX  XXX 

XXX  XXX 

XXXXX 

YC 

XXX 

XXX 

XXX 

XXX 

XXX  XXX 

XXX  XXX 

XXXXX 

YD 

XXX 

XXX 

XXX 

XXX 

XXX  XXX 

XXX  XXX 

XXXXX 

YE 

XXX 

XXX 

XXX 

XXX 

XXX  XXX 

XXX  XXX 

XXXXX 

Total 

XXXXX 

XXXXX  XXXXX  XXXXX 

XXXXX  XXXXX 

XXXXX  XXXXX 

XXXXX 

F igu  re 

I I I- 13 

5 

Average  Number  of 

Days  to  Obtain  NSN 

from  IMM  (Figure  III-14) 

.  This 

report  shows  the  average 

number 

of  days 

taken 

by  IMM  to 

furnish 

the  NSNs  received  in  this  pro- 

cessing 

cycle 

AVERAGE 

NUMBER  OF  DAYS  REQUIRED 

TO  OBTAIN 

NSN  FROM  IMM 

Date  XXXXX 

Number  NSNs  Received 

Average 

IMM 

this 

Cycle 

Number  Days 

AX 

XXX 

XXX 

CX 

XXX 

XXX 

KX 

XXX 

XXX 

TX 

XXX 

XXX 

AZ 

XXX 

XXX 

KZ 

XXX 

XXX 

7  5 

XXX 

XXX 

W  IMMs 

XXX 

Total 

XXXX 

Figure  III-14 
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2.  WIMM  SSR  Application  (Phase  II).  Phase  II  of  the  SSR 
application  processes  incoming  SSR  transactions  sent  to  the  Navy 
as  the  WIMM.  Phase  II  is  shown  in  Figure  III-15  and  is  a  batch 
sequential  process  recommended  to  be  scheduled  on  a  weekly 
basis.  As  with  the  outgoing  phase  discussed  above,  scheduling 
is  done  on  a  program  rather  than  a  job  stream  basis.  Processing 
generally  takes  place  on  L1SSR  transaction  packages  rather  than 
single  transactions. 

a.  WIMM  SSR  Validation.  This  program  module  validates 
individual  data  elements  and  document  combinations  of  input  SSR 
transactions,  LIAC  transactions  and  Internal  File  Maintenance 
transactions  and  generates  reject  advice  transactions  for  those 
found  inval id . 

(1)  Inputs  .  Transactions  may  be  input  to  this 
program  module  either  directly  as  cards  or  a  card  to  tape  util¬ 
ity  may  be  used  to  transfer  the  cards  to  a  magnetic  tape  which 
is  then  used  as  input. 

(2)  Files  .  No  files  are  accessed  by  this  program 

module  . 

(3)  Processing.  All  input  transactions  are  first 
sorted  into  PCC,  ACF,  DOR,  ISN,  DIC,  TCC  and  Card  Number  se¬ 
quence.  Then  each  transaction  is  validated  for  correct  format 
and  content  with  the  exception  of  followup  transactions  which 
bypass  all  validations  other  than  DIC.  Locally  generated  (CXZ) 
transactions  which  update  the  WIMM  SSR  Suspense  File  and  cause 
advice  transaction  generation  are  validated  for  proper  entries. 
When  validation  errors  are  found  in  transactions  received  from  a 
SICC,  a  reject  advice  transaction  containing  an  ATC  from  the  I  MM 
Manual  is  automatically  generated  to  notify  the  submitter  of  the 
error.  When  errors  are  found  in  locally  generated  transactions 

a  Navy  unique  error  code  is  placed  in  the  transaction.  After 
validation  all  input  transactions  plus  those  advice  transactions 
generated  by  this  program  module  are  output  to  the  WIMM  SSR 
transaction  file. 

(4)  Ou  t  pu  t  .  The  single  output  from  this  program 
module  is  the  WIMM  SSR  transaction  file  shown  in  Figure  1 1 1  —  1 5 . 

b.  WIMM  SSR  File  Maintenance.  This  program  module  per¬ 
forms  file  maintenance  on  the  WIMM  SSR  Suspense  File,  attempts 
to  make  advice  decisions  on  valid  SSRs  transactions  received, 
generates  responses  to  followup  transactions  generated  by  the 
SICC,  generates  advice  transactions  for  incoming  SSR  transac¬ 
tions  on  which  manual  advice  decisions  were  made,  and  generates 
internal  followups  when  required  actions  are  overdue. 
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SSR  APPLICATION  (PHASE  II) 
(INCOMING  SSRs) 


(1)  Input  .  Input  to  this  program  module  consists 
of  the  WIMM  SSR  transaction  file  output  from  the  previous  pro¬ 
gram  module. 

(2)  Files 


(a)  WIMM  SSR  Suspense  File.  This  is  a  sequen¬ 
tial  magnetic  tape  file  made  up  of  valid  and  invalid  incoming 
SSR  transactions  and  valid  internal  transactions  (DIC  =  CXZ). 

This  file  is  sequenced  on  PCC ,  ACF,  DOR,  ISN,  Transaction  Date, 
DIC,  and  Card  Number.  This  file  is  structured  parallel  to  the 
SICC  SSR  Suspense  File  with  100  character  records  made  up  of  80- 
position  card  images  followed  by  data  for  internal  use.  The  WIMM 
SSR  Suspense  File  records  all  contain  a  5-position  Julian  pro¬ 
cess  date  in  positions  81-85.  All  records  except  PDSSR  records 
and  the  second  card  of  a  part  number  SSR  combination  contain  an 
SSR  Status  Code  in  position  86  and  a  Julian  completion  date  in 
positions  87-91.  The  remaining  positions  are  blank.  The  PDSSR 
records  contain  blanks  in  positions  86-100  and  the  second  card 

of  a  part  number  SSR  combination  contains  an  SSR  Status  Code  in 
position  86  followed  by  blanks  in  positions  87-100.  The  WIMM 
SSR  Suspense  File  contains  the  following  types  of  transactions: 

_1_  PDSSR  Transactions 

2_  LISSR  Transactions 

Item  Name  Transactions 

Additional  Reference  Transactions 

5^  Additional  User  Transactions 

6^  Advice  Transactions 

7_  Offer  Reply  Transactions 

Followup  Transactions 

_9  Followup  Response  Transactions 

1 0  Internal  File  Maintenance  Transactions 

( b )  Local  Total  item  Record  (TIR)  File . 

( c )  Major  Organizational  Entity  (MOE)  File. 

(3)  Processing.  Transactions  from  the  WIMM  SSR 
Transaction  File  are  read  and  matched  against  the  WIMM  SSR 
Suspense  File  on  PCC,  ACF,  and  ISN  to  ensure  proper  placement  in 


the  file  for  SSRs  that  are  initial  submissions,  or  as  an  addi¬ 
tional  validation  (duplicate  check)  in  the  case  of  other  trans¬ 

actions.  Once  this  is  done,  the  SSR  transactions  are  checked  to 
see  if  an  invalid  condition  was  found  by  the  previous  program 
module.  Those  that  were  found  to  be  invalid  are  posted  to  the 
WIMM  SSR  Suspense  File  along  with  the  associated  advice  transac¬ 
tion.  These  advice  transactions  are  output  as  WIMM  advice  trans¬ 
actions.  These  SSR  transactions  are  then  considered  complete. 

(a)  Cataloging  Transaction  Generation.  Valid 
initial  submission  LISSR  transactions  containing  an  NSN  are 
checked  against  the  local  TIR  file  to  determine  if  the  request 

is  for  an  item  actively  managed  by  the  I  MM .  If  it  is  not  found 

on  t!ie  local  TIR  File,  i.  t  is  output  for  manual  review.  If  it  is 
found  on  the  local  TIR  File,  the  MOE  Rule  in  the  local  TIR  File 
is  checked  to  see  if  the  SICC  Service  is  recorded.  When  th- 
SIC'C  Service  is  not  recorded  and  the  SSR  transaction  contains  a 
valid  MOE  Rule  based  on  a  match  to  the  MOE  Rule  File,  an  Add 
User  transaction  is  generated  and  output  to  the  DLSC  Transaction 
File.  When  the  SICC  is  another  Navy  activity  and  the  SSR  trans¬ 
action  contains  a  valid  MOE  Rule,  an  <idd  data  collaborator/re¬ 
ceiver  transaction  Is  generated  for  each  Item  Identifier  II  Data 
Receiver  and  II  Data  Collaborator  contained  in  the  SSR  transac- 
tion  and  is  output  to  the  DLSC  Transactions  File.  When  an  invalid 
MOE  Rule  is  encountered  the  SSR  transaction  is  posted  to  the  WIMM 
SSR  Suspense  File  and  a  reject  advice  transaction  is  generated, 
posted  to  the  WIMM  SSR  Suspense  File  and  output  as  an  advice 
transaction. 


( b )  Advice  D  etermlnation 

Those  LISSR  transactions  which  matched  the 
local  TIR  rLle  and  contained  a  valid  MOE  Rule  are  checked  against 
local  ICP  criteria  to  determine  if  they  must  be  output  for  manual 
review.  This  local  ICP  criterion  differs  between  ASO  and  SPCC, 
but  contains  such  things  as  the  item  Is  not  managed  as  a  con¬ 
sumable,  the  AAC  is  "J"  (centrally  procured,  nonstocked),  and 
the  date  repair  parts  required  is  not  180  days  greater  than  the 
i.ue  the  item  was  established  on  the  local  TIR  File.  Trans¬ 
actions  that  meet  any  of  the  local  ICP  criteria  are  output  for 
manual  review  and  posted  to  the  WIMM  SSR  Suspense  File.  Trans¬ 
actions  not  meeting  any  of  the  criteria  are  posted  to  the  WIMM 
SIR  Suspense  File  and  accept  advice  transactions  are  generated 
with  A TO  "YE”  (unconditional  support  accepted).  The  advice 
transaction  is  posted  to  the  WIMM  SSR  Suspense  File  and  output 
as  a  WIMM  advice  transaction.  When  an  accept  advice  is  being 
returned  to  a  SICC,  the  rt  tall  and  replenishment  quantities  in 
the  SSR  transaction  are  examined  for  a  nonzero  condition.  When 
either  ir  both  quantities  are  nonzero,  planned  requirements 
’  ■'  a  1 1 «  i  c  t  i  o  n  s  are  output. 


All  valid  LISSR  transactions  without  an 
NSN  and  1 j  LSSR  change  transactions  are  automatically  output 
for  manual  »~view  and  posted  to  the  WIMM  SSR  Suspense  File. 
Transactions  output  for  manual  review  are  listed  on  the  Individual 
SSR  List  and  a  skeleton  CXZ  transaction  is  generated  for  each. 

The  manual  review  determines  the  advice  to  be  returned  to  the 
SICC.  This  advice,  In  addition  to  advice  related  data  such  as  an 
alternate  support  date,  are  entered  in  the  CXZ  transaction.  The 
CXZ  transaction  is  then  input  to  the  next  processing  cycle  of 
Phase  II  and  is  validated  In  the  WIMM  SSR  Validation  Program 
Module.  When  this  program  module  identifies  a  CXZ  transaction, 

It  Is  checked  to  determine  if  it  passed  validation,  and  if  not, 
it  Is  simply  output  as  is  for  correction  and  reinput.  If  valid, 
an  advice  transaction  is  generated,  posted  to  the  WIMM  SSR 
Suspense  File  and  output  as  a  WIMM  advice  transaction.  This 
advice  transaction  may  contain  accept,  offer,  reject  or  other 
advice.  If  the  advice  is  accept,  planned  requirements  data  may 
be  generated  as  discussed  above. 

(c)  Offer  Reply  Processing.  Offer  Reply  Trans¬ 
actions,  when  identified  by  this  program  module,  are  matched 
against  the  WIMM  SSR  Suspense  File.  If  a  no  match  condition 
occurs;  the  transaction  receives  an  internal  error  code  overlayed 
in  the  ATC  field  and  is  output  for  manual  review.  These  trans¬ 
actions  are  not  posted  to  the  WIMM  SSR  Suspense  File.  When  a 
match  for  the  transaction  is  found  and  the  Offer  Reply  Transac¬ 
tion  is  accompanied  by  an  advice  transaction  (meaning  that  an 
invalid  condition  was  found  in  the  validation  program  module) 
the  only  action  taken  on  the  offer  reply  transaction  is  posting 
to  the  WIMM  SSR  Suspense  File.  The  advice  transaction  is  output 
and  is  also  posted  to  the  WIMM  SSR  Suspense  File.  Other  Offer 
Reply  Transactions  are  posted  to  the  WIMM  SSR  Suspense  File  and 
are  output  along  with  their  matching  records  on  the  Individual 
SSR  List  for  manual  review. 


(d)  Incoming  Followup  Processing.  When  follow¬ 
up  transactions  are  received,  they  are  matched  to  the  WIMM  SSR 
Suspense  File  on  PCC,  ACT  and  ISN.  If  a  No  Match  condition 
occurs,  a  Followup  Response  Transaction  is  generated  with  an 
ATC  of  "66"  (no  record)  and  is  output  as  an  advice  transaction. 
When  a  match  Is  found  and  one  or  more  advice  transactions  are 
present,  a  Followup  Response  Transaction  will  be  generated  con¬ 
taining  the  same  ATC  as  the  latest  advice  transaction  on  the 
file.  If  that  advice  transaction  was  created  earlier  in  this 
processing  cycle,  it  is  treated  as  an  exception  and  no  Followup 
Response  will  be  generated.  When  a  match  condition  occurs  and 
no  advice  transactions  are  present  on  the  file,  the  current  date 
is  checked  against  the  date  the  initial  submittal  was  introduced 
to  the  file.  If  less  than  25  days  have  passed,  no  action  is 
taken  on  the  followup  transaction.  When  pore  than  25  days  have 
passed,  the  matching  records  are  output  on  the  Individual  SSR 
List  for  manual  review.  In  all  cases,  the  followup  transaction 
and  the  subsequent  followup  response  transaction  (when  generated) 
are  posted  to  the  WIMM  SSR  Suspense  File. 


(e)  File  Purge.  This  prograa  module  perforas 
three  actions  which  are  not  based  on  an  Input  transaction.  When 
a  group  of  SSR  transactions  coded  as  coaplete  Is  encountered 
during  the  processing  cycle,  the  coapletion  date  is  coapared  to 
the  current  date.  When  the  difference  between  these  dates  is  at 
least  180  days  the  record  group  is  purged  froa  the  file.  SSR 
transactions  are  considered  coaplete  when  reject  advice  is  sent 
to  the  SICC,  accept  advice  with  an  NSN  is  sent  to  the  SICC,  or 
reply  to  an  offer  Indicates  acceptance  of  the  offered  NSN  item. 

(f)  External  Followups.  When  a  group  of  SSR 
transactions  is  encountered  in  which  the  latest  advice  indicates 
an  offer  was  sent  to  the  SICC,  the  current  date  is  coapared  to  the 
date  the  offer  transaction  was  generated.  An  advice  transaction 
containing  ATC  "08"  (no  response  to  offer)  will  be  generated, 
posted  to  the  WIMM  SSR  Suspense  File  and  output  as  an  advice  trana 
action  when  the  difference  between  these  dates  is  over  60  days. 

(g)  Internal  Followups.  Internal  ICP  follow¬ 
ups  will  be  output  on  the  Individual  SSR  List  when  an  initial 
advice  transaction  has  not  been  reinput  for  processing  within  15 
days  of  the  receipt  of  the  LISSR  transaction.  These  followups 
will  also  be  output  when  an  accept  advice  transaction  for  a 
LISSR  transaction  containing  a  Part  Number  or  PSCN  has  not  been 
followed  by  another  advice  transaction  containing  the  required 
NSN  within  60  days  of  receipt  of  the  LISSR  transaction. 

(h)  Report  Generation.  Final  actions  taken 
during  each  cycle  by  this  program  module  are  to  produce  the  WIMM 
SSR  Suspense  File  List  which  is  a  printout  of  the  current  WIMM 
SSR  Suspense  File  in  total,  and  to  produce  two  statistical  re¬ 
ports.  The  formats  of  these  reports  are  shown  in  Figures  III-16 
and  III-17 . 
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Figure  III-17 

(i)  Change  Processing.  All  changes  allowed  by 
the  IMM  Manual  may  be  input  to  Phase  II.  Processing  of  all 
changes  except  superseding  items  consists  simply  of  validation, 
entry  to  the  WIMM  SSR  Suspense  File,  and  output  for  manual 
review.  Superseding  item  changes  are  processed  as  if  they  are 
initial  submittals. 

(4)  Outputs 

(a)  Planned  Requirements  Data.  This  data  is 
input  to  another  application  which  uses  this  information  in 
requirements  forecasting  and  requirements  determination  actions 
to  meet  SSR  requirements. 

(b)  DLSC  transactions.  These  are  transactions 
to  update  the  MOE  Rule,  registered  user,  or  Item  Identification 
data  receiver/collaborator  information  on  the  DIDSTIR  File. 

(c)  WIMM  Advice  Transactions.  Advice  and 
Followup  Response  Transactions  to  be  sent  to  the  SICC.  These 
transactions  are  sorted  into  ACT,  PCC,  ISN,  DOR,  DIC,  and  Card 
Number  sequence  before  they  are  output  aB  cards. 

(d)  CXZ  Transactions.  These  Internal  transac¬ 
tions  are  completed  by  the  ICP  and  are  used  when  an  advice  deci¬ 
sion  cannot  be  made  automatically. 
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(e)  WIMM  SSR  Suspense  File  List.  This  is  a 
complete  printout  of  the  current  WIMM  SSR  Suspense  Pile  and  is 
produced  as  the  final  processing  action  each  cycle. 

(f)  Individual  SSR  List.  This  list  contains 
SSR  transactions  on  which  some  manual  action  is  required  as 
determined  during  the  processing  cycle  -  initial  submission  SSR 
requires  advice,  change  submission  requires  action.  Internal 
followups,  etc. 


(g)  WIMM  Statistics.  Two  reports  are  produced. 


1^  Number  of  Incoming  SSRs  Received.  The 
format  for  this  report  is  shown  in  Figure  III-16.  A  count  is 
iven  of  the  number  of  line  items  received  by  PCC  and  SICC  as 
ell  as  a  total  count  of  items  received  in  the  processing  cycle. 

2_  Number  of  Advice  Transactions  Produced 
for  Incoming  SSRs.  The  format  for  this  report  is  shown  in 
Figure  III-17.  Counts  are  produced  of  the  number  of  advice 
transactions  generated  by  ATC  for  each  SICC.  A  total  for  each 
SICC  and  each  ATC  for  the  processing  cycle  is  also  shown. 
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CHAPTER 


AIR  FORCE 


A.  INTRODUCTION 

The  Air  Force  develops  its  standard  automated  systems  under 
an  Automated  Data  System  (ADS)  Manager  concept  as  opposed  to  the 
SDA  concept  used  by  the  other  Services.  Under  this  concept,  a 
single  project  manager  is  assigned  to  oversee  the  design,  devel¬ 
opment,  and  implementation  of  a  single  Computer  Program  Configura¬ 
tion  Item  (CPCI).  A  CPCI  may  include  a  total  ADS  or  a  portion 
thereof;  for  example,  an  ADS  may  consist  of  several  applications 
tied  together  by  a  single  data  base,  and  a  CPCI  may  be  designated 
for  each  application.  Each  CPCI  may  be  designed  and  developed 
by  a  project  manager  at  Headquarters  Air  Force  Logistics  Command 
(AFLC)  or  a  project  manager  may  be  assigned  and  the  CPCI  designed 
and  developed  at  a  Headquarters  AFLC  subordinate  activity.  The 
Supply  Support  Request  (SSR)  Subsystem  in  the  Air  Force  was 
designed  and  developed  as  a  stand-alone  ADS  under  a  single  CPCI 
for  Implementation  at  all  Air  Logistics  Centers  (ALCs). 

B.  SYSTEMS  DESIGN  PROCESS 


The  Office  of  Primary  Responsibility  (OPR)  for  SSR  processing 
within  the  Air  Force  is  the  Interservice  and  Interagency  Support 
Office  under  the  Deputy  Chief  of  Staf f /Logis t ic s  within  Head¬ 
quarters,  Air  Force  Logistics  Command.  This  Office  has  respon¬ 
sibility  for  the  Implementation  of  the  IMM  Manual  and  establishes 
policy  and  procedures  relating  to  the  automated  or  manual  genera¬ 
tion  and  processing  of  SSRs .  Since  an  automated  SSR  subsystem 
existed  in  the  Air  Force  prior  to  development  of  the  IMM  Manual, 
it  required  modification  to  conform  with  policy,  procedures  and 
formats  in  the  IMM  Manual  dated  May  1978.  The  Interservice  and 
Interagency  Support  Office  is  responsible  for  identifying  the 
modification  requirements  and  initiating  action  to  complete 
required  modifications  by  the  required  implementation  date.  To 
fulfill  this  responsibility  a  Data  Automation  Requirement  (DAR) 
was  developed  to  document  the  modifications  needed. 

The  organizational  structure  within  AFLC  involved  with  auto¬ 
mated  SSR  generation  and  processing  and  related  functional  areas 
is  shown  in  Figure  IV-1.  As  this  figure  illustrates,  the  func¬ 
tional  office  of  primary  responsibility  lies  within  the  Deputy 
Chief  of  Staff  ( DCS ) /Log is t i cs  Operations;  ADS  development  and 
operations  responsibility  lies  within  the  DCS/Comptroller ,  and 
operational  processing  is  the  responsibility  of  the  individual 


ALCs.  The  AFLC  Cataloging  and  Standardization  Office  is  respon¬ 
sible  for  cataloging  and  standardization  interfaces.  The  Direc¬ 
torate  of  Logistics  Management  Is  functionally  responsible  for 
provisioning  interfaces  and  the  Directorate  of  Materiel  Require¬ 
ments  is  functionally  responsible  for  the  requirements  determina¬ 
tion  interfaces.  The  DCS/Comptroller  is  responsible  for  the 
design,  development  and  implementation  of  automated  systems  to 
support  the  SSR  and  related  functions.  The  Data  Automation 
Requirement  developed  by  the  Interservice  and  Interageny  Support 
Office  is  analyzed  in  the  Directorate  ADP  Resources.  This  direc¬ 
torate  may  determine  that  the  requirement  be  designed,  developed 
and  implemented  by  Headquarters  AFLC  personnel  or  the  require¬ 
ment  may  be  forwarded  to  the  Comptroller  of  an  Air  Force  Base 
(AFB)  colocated  with  one  of  the  ALCs  for  design,  development  and 
implementation.  The  ALCs  do  not  maintain  an  ADP  staff  themselves, 
but  rely  on  the  ADP  staff  of  the  AFB  with  which  they  are  colocated 
for  programming  and  operational  support. 

The  SSR  Subsystem  in  existence  prior  to  the  development  of 
the  new  IMM  Manual  had  been  designed,  developed  and  implemented 
by  the  ADP  staff  at  the  AFB  colocated  with  Sacramento  ALC  (SMALC) 
and  the  new  requirement  was  also  forwarded  to  this  ADP  staff. 

The  organizational  alignment  of  this  ADP  staff  is  shown  in  Figure 
IV-2.  As  shown  in  the  figure,  the  SSR  Subsystem  was  assigned  to 
the  Weapon  System  Support  Unit  for  design  and  development. 

In  the  Air  Force,  CPCIs  are  designed,  developed  and  imple¬ 
mented  in  a  five-step  process.  The  first  step  is  termed  "concep¬ 
tual"  and  includes  the  development  of  a  Data  Automation  Require¬ 
ment  and  a  Functional  Description.  For  the  SSR  Subsystem,  the 
data  automation  requirement  was  developed  by  the  Interservice 
and  Interagency  Support  Office.  The  Functional  Description  was 
developed  as  a  combined  effort  by  the  Interservice  and  Inter¬ 
agency  Support  Office,  the  Weapon  System  Support  Unit  and  SMALC 
functional  personnel. 

The  definition  step  (Step  2)  follows  the  conceptual  step  and 
consists  of  development  of  a  subsystem  specification.  This  sub¬ 
system  specification  may  be  a  functionally  oriented  or  ADP 
oriented  document.  For  the  SSR  Subsystem  it  is  an  ADP  oriented 
document  developed  by  the  Weapon  System  Support  Unit. 

The  development  step  (Step  3)  follows  the  definition  step. 

This  step  includes  the  design,  programming,  and  testing  of  each 
program  module.  This  step  was  performed  by  the  Weapon  System 
Support  Unit  for  the  SSR  Subsystem. 

The  fourth  step  is  a  separate  test  step  following  develop¬ 
ment  to  insure  proper  interfacing  between  program  modules.  Imple¬ 
mentation  documentation  is  also  initiated  at  this  point. 
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GROUP  ORGANIZATIONAL  STRUCTURE 


An  operational  test  step  (Step  5)  at  a  prototype  activity  is 
performed  last  to  insure  proper  operation  with  Interfacing  applica¬ 
tions  and  to  prepare  final  implementing  documentation.  The  proto¬ 
type  activity  for  the  SSR  Subsystem  was  SMALC. 

One  or  more  review  processes  may  occur  in  or  between  steps 
and  a  final  operational  review  is  performed  subsequent  to  the 
operational  test  leading  to  implementation  by  all  ALCs.  The  SSR 
Subsystem  was  designed,  developed  and  implemented  in  two  applica¬ 
tions.  The  Daily  SSR  Application  includes  processing  on  a  daily 
basis  and  was  completed  and  implemented  concurrently  with  the 
IMM  Manual.  The  Monthly  SSR  Application  handles  monthly  pro¬ 
cessing  and  was  scheduled  for  implementation  by  30  June  1978. 

The  automated  implementation  package  sent  to  the  ALCs  gener¬ 
ally  includes  a  program  maintenance  manual,  a  computer  operations 
manual  and  a  duplicate  of  the  programs  included  in  the  subsystem/ 
application . 

C.  SYSTEM  DOCUMENTATION 

The  initiating  document  is  generally  a  Data  Automation  Re¬ 
quirement  developed  by  the  functional  office  of  primary  respon¬ 
sibility  at  Headquarters  AFLC.  This  is  followed  by  development 
of  a  Functional  Description  which  sets  forth  the  functional 
requirements  to  be  performed  by  the  ADS  and  is  generally  devel¬ 
oped  by  functional  and  ADP  personnel.  This  is  followed  by  devel¬ 
opment  of  a  subsystem  specification  by  ADP  personnel  which  docu¬ 
ments  functional  requirements  in  an  ADP  oriented  format.  Below 
this  level  Program  Specifications  and  Implemention  Documents 
exist . 

Program  specifications  are  not  generally  published  or  distrib¬ 
uted  and  consist  of  programmer  specifications  and  notes,  program 
listings,  test  data  and  results.  The  detailed  program  criteria 
is  usually  located  only  at  this  level;  e.g.,  validation  criteria, 
suspenses,  etc. 

The  implementation  documentation  in  the  ADP  area  is  developed 
by  ADP  personnel  and  consists  of  a  Program  Maintenance  Manual  and 
an  Operations  Manual.  The  Program  Maintenance  Manual  allows  each 
implementing  activity  the  capability  of  maintaining  each  program 
with  the  subsystem/application.  The  operations  manual  provides 
instructions  to  computer  operations  personnel  to  allow  them  to 
execute  programs  within  the  application  in  proper  sequence  with 
the  proper  Inputs,  outputs  and  files. 

Documentation  for  functional  users  and  training  is  the 
responsibility  of  the  functional  office  of  primary  responsibility 
at  Headquarters  AFLC.  A  Functional  Users  Manual  was  developed 


for  the  SSR  Subsystem  at  Headquarters  AFLC.  Additional  user 
documentation  may  be  developed  in  the  appropriate  functional 
area  at  each  ALC. 

D.  SYSTEM  OVERVIEW 


The  SSR  Subsystem  in  the  Air  Force  was  designed  and  imple¬ 
mented  as  a  stand-alone  application.  An  overview  of  this  sub¬ 
system  and  the  interfacing  Provisioning  Subsystem  is  shown  in 
Figure  IV-3.  As  shown  in  this  figure,  outgoing  provisioning  SSR 
candidates  and  advice  transactions  may  enter  the  subsystem 
mechanically.  Outgoing  provisioning  and  nonprovisioning  SSR 
transactions,  incoming  SSR  transactions,  advice  transactions, 
and  local  functional  inquiries  are  also  input  to  the  SSR  sub¬ 
system  on  a  manual  basis.  Both  of  these  processing  blocks  will 
be  discussed  on  a  general  basis. 

1.  Provisioning  Subsystem.  The  Provisioning  Subsystem,  like 
the  SSR  Subsystem,  was  designed  and  developed  by  the  comptroller 
element  at  the  base  level.  The  subsystem  was  designed  and  devel¬ 
oped  by  a  data  processing  organization  colocated  with  Ogden  ALC 
(OOALC).  This  subsystem  was  assigned  to  that  activity  to  be 
completed  for  implementation  in  time  for  use  in  provisioning  the 
F-16  A/B  Weapon  System.  Prior  to  the  development  of  this  sub¬ 
system,  provisioning  was  done  on  a  manual  basis. 

a.  Inputs .  Input  to  the  provisioning  subsystem  includes 
provisioning  data  in  MIL-STD-1552  format  (Appendix  D,  Reference 
22),  local  functional  interrogations.  Technical  Review  Update 
Transactions,  Provisioning  Update  Transactions  and  Item  Manager 
(IM)  Review  Update  Transactions. 

(1)  Provisioning  Data.  This  data  is  submitted  by 
the  contractor  in  mechanized  formats. 

(2)  Local  Functional  Interrogations.  These  are 
interrogations  into  the  PCCN  Master  File  or  the  PLISN  Master 
File. 

(3)  Technical  Review  Update  Transactions.  These 
are  transactions  to  update  the  PLISN  Master  File  with  technical 
data,  e.g.,  SM&R  codes. 

(4)  IM  Review  Update  Transactions.  These  are  trans¬ 
actions  to  update  the  PLISN  Master  File  with  IM  data;  e.g., 
failure  factors. 

(5)  Provisioning  Update  Transactions.  These  are 
transactions  from  the  SSR  Subsystem  to  return  advice  to  the  pro¬ 
visioning  subsystem  and  clear  the  suspense  on  the  SSR  Candidate 
Suspense  File. 
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b.  Files  .  There  are  four  major  files  used  by  the  pro¬ 
visioning  subsystem  as  shown  in  Figure  IV-3.  These  files  are 
the  PCCN  Master  File,  the  PLISN  Master  File,  the  PLISN  Suspense 
File  and  the  SSR  Candidate  Suspense  File. 

( 1 )  Provisioning  Contract  Control  Number  (PCCN) 

Master  File.  This  is  a  sequential  disk  file  with  fixed  length 
records  and  contains  program  data  as  well  as  data  to  control  the 
automated  provisioning  process  as  a  whole. 

(  2 )  Provisioning  Line  Item  Serial  Number  (PLISN) 
Master  File.  This  sequential  disk  file  contains  provisioning 
data  on  an  item  by  item  basis.  It  acts  as  an  active  and  a  history 
file.  There  is  no  specific  retention  for  records  on  this  file 
and  purge  of  items  from  the  file  must  be  manually  initiated. 

(3 )  Provisioning  Line  Item  Serial  Number  (PLISN) 
Suspense  File.  This  file  contains  a  record  of  items  undergoing 
active  provisioning  processing  until  complete  or  until  an  SSR 
candidate  is  generated. 

(4)  SSR  Candidate  Suspense  File.  This  fila  con¬ 
tains  items  for  which  SSR  candidate  transactions  were  generated 
for  processing  by  the  SSR  Subsystem.  Items  remain  on  this  file 
until  proper  provisioning  update  data  is  received  from  the  SSR 
Subsystem  to  complete  this  item  and  clear  the  suspense. 

c .  Processing 


Initial  processing  in  the  Provisioning  Subsystem 
consists  of  loading  appropriate  data  to  the  PCCN  Master  File. 

This  includes  program  data  and  a  schedule  of  provisioning 
actions  required.  This  schedule  is  used  by  the  provisioning 
subsystem  to  push  each  item  through  the  provisioning  process 
once  it  is  loaded  to  the  PLISN  Master  File. 

When  the  provisioning  data  is  received  from  the  con¬ 
tractor,  it  is  validated  for  format  and  content,  and  is  used  to 
load  the  PLISN  Master  File.  When  this  is  completed,  the  schedule 
on  the  PCCN  Master  File  is  checked  to  determine  if  technical 
review  is  required.  If  so,  the  provisioning  subsystem  will  auto¬ 
matically  assign  some  provisioning  data  when  it  is  not  present 
in  the  PLISN  Master  File  (SM&R  codes  (for  FSCs  5300  and  5900), 
IMC,  and  Demilitarization  Codes).  Each  item  is  output  on  a 
Technical  Review  Document  and  is  reviewed  by  a  provisioning 
technician  who  assigns  additional  technical  data  required,  and 
may  alter  the  computer  assigned  data.  When  the  Technical  Review 
Document  is  produced,  a  record  is  placed  on  the  PLISN  Suspense 
File  that  tb a  item  was  output  for  technical  review.  When  a 
technical  review  update  transaction  Is  not  received  in  ten  days, 
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a  delinquency  notice  is  output  by  the  provisioning  subsystem  to 
the  provisioning  technician.  A  technical  review  update  transac¬ 
tion  must  be  input  for  each  item  output  for  technical  review 
regardless  of  whether  the  review  resulted  in  additions  or  changes 
to  data. 


Input  of  technical  review  update  transactions  to  the 
provisioning  subsystem  updates  the  PLISN  Master  File  and  clears 
the  suspense  from  the  PLISN  Suspense  File.  At  this  point  items 
not  source  coded  in  the  'P  *  series  become  inactive.  Items  that 
are  source  coded  in  the  ’P  '  series  are  automatically  divided 
into  two  groups:  items  currently  managed  by  another  Service,  DLA 
or  GSA;  and  new  items  with  I MC  equal  to  Z  are  output  as  SSR  can¬ 
didates.  Part  Number  SSR  candidates  are  also  printed  on  the  SSR 
Required  Drawings  List.  Items  for  which  SSR  Candidates  are  gener¬ 
ated  are  placed  on  the  SSR  Candidate  Suspense  File.  The  second 
group  of  items  are  output  on  IM  Review  Documents  and  consist  of 
items  already  managed  by  the  Air  Force,  new  items  to  be  managed 
by  the  Air  Force  or  nonconsumable  items  requiring  NIMSR  prepara¬ 
tion  and  submittal.  Items  output  on  IM  Review  Documents  are 
placed  on  the  PLISN  Suspense  File  under  a  ten-day  suspense.  The 
item  manager  must  input  an  IM  Review  Update  Transaction  for  each 
item  output  on  an  IM  Review  Document. 

IM  Review  Update  Transactions  input  to  the  provi¬ 
sioning  subsystem  automatically  update  the  PLISN  Master  File  and 
clear  the  suspense  from  the  PLISN  Suspense  File.  A  Provisioning 
Items  Order  (PIO)  tape  is  produced  for  those  items  to  be  initially 
procured  on  the  end  item  contract  and  a  Contractor  Notification 
Tape  is  produced  for  items  that  reached  final  status  during  the 
processing  cycle. 

Processing  in  this  subsystem  is  sequential  and  on  an 
item  basis.  This  subsystem  consists  of  several  program  modules 
run  in  a  single  job  stream  and  is  recommended  to  be  executed  on 
a  daily  processing  cycle  basis.  As  indicated  in  Figure  IV-3, 
when  the  provisioning  subsystem  detects  a  Design  Change  Notice 
has  been  input  as  provisioning  data,  it  is  automatically  output 
for  manual  action  by  the  provisioning  organization.  The  Provi¬ 
sioning  Subsystem  does  no  requirements  computations.  These  must 
be  done  manually  outside  of  the  system.  There  is  an  initial 
requirements  computation  application  under  development  by  the 
Air  Force  which  is  intended  to  interface  with  this  provisioning 
subsystem  when  completed. 

The  relationships  between  the  SSR  candidate  transac¬ 
tions,  the  SSR  Candidate  Suspense  File,  and  Provisioning  Update 
Transactions  are  discussed  later  In  this  section. 

d.  Outputs .  There  are  several  outputs  from  the  provi¬ 
sioning  subsystem  as  shown  in  Figure  IV-3. 
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(1)  Contractor  Notifications.  These  are  notifica¬ 
tions  to  the  contractor  relating  final  status  on  each  item  in 
the  provisioning  package. 

(2)  Provisioning  Items  Order  (PIO)  Tape.  This 
magnetic  tape  contains  those  items  for  which  initial  require¬ 
ments  are  to  be  procured  from  the  end  item  manufacturer. 

(3)  Design  Change  Notice  (DCN)  Documents.  These 
are  DCNs  output  for  manual  action.  No  automated  processing  of 
DCNs  is  done. 

(4)  SSR  Candidate  Transactions.  This  is  a  magnetic 
tape  file  of  transactions  to  be  processed  by  the  SSR  Application. 


(5)  SSR  Required  Drawings  List.  This  is  a  list  of 
Part  Number  SSR  Candidates  generated.  The  provisioner  is  to  use 
this  list  to  pull  drawings  from  his  files  to  accompany  these  SSR 
transactions  to  the  IMM. 

(6)  Technical  Review  Documents.  These  are  documents 
containing  provisioning  data  output  to  the  provisioning  technician 
for  review  and  update. 

(7)  Item  Management  (IM)  Review  Documents.  These 
are  documents  containing  provisioning  data  output  to  the  item 
manager  for  review  and  update. 

(8)  Provisioning  Outputs.  There  are  several  other 
hard  copy  outputs  produced  by  the  provisioning  subsystem.  These 
have  no  bearing  on  the  SSR  process  and  are  not  described  here. 

(9)  Delinquency  Notices.  These  are  output  to  the 
functional  area  when  an  item  on  the  PLISN  Suspense  File  becomes 
overdue  and  action  is  not  received. 

2 .  SSR  Subsystem 

The  SSR  Subsystem  in  the  Air  Force  consists  of  two 
applications,  a  daily  processing  application  and  a  monthly  pro¬ 
cessing  application.  A  general  discussion  of  the  processing  in 
both  applications  is  given  here  with  a  detailed  discussion  of 
each  following.  This  subsystem  is  designed  to  process  outgoing 
and  incoming,  provisioning  and  nonprovisioning  PDSSR  transac¬ 
tions,  LI  SSR  transactions,  Catalog  transactions  and  Advice 
transactions . 

Outgoing  SSR  transactions  are  validated,  screened  against 
DLSC  files,  and  file  maintained.  Followup  transactions  are 
automatically  generated  and  Advice  transactions  are  validated 
and  file  maintained. 
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Incoming  SSR  transactions  are  validated  with  automatic 
generation  of  reject  advice  transactions,  and  file  maintained. 
Other  automated  processing  includes  generation  of  cataloging 
transactions  and  generation  of  followup  response  transactions. 

a.  Inputs .  There  are  several  inputs  to  this  subsystem 
as  illustrated  in  Figure  IV-3. 

(1)  Local  Catalog  File  Replies.  These  are  replies 
to  interrogations  generated  by  this  subsystem.  The  file  inter¬ 
rogated  is  a  local  file  containing  abbreviated  cataloging  data 
(ALC  Master  Cross  Reference  File). 

(2)  DLSC  Replies.  These  are  replies  to  DLSC  screen¬ 
ing  transactions  generated  by  this  subsystem. 

(3)  SSR  Candidates .  These  are  outgoing  provisioning 
SSR  candidate  transactions  generated  by  the  automated  provision¬ 
ing  subsystem. 

(4)  Outgoing  SSR  Transactions.  These  are  manually 
generated  provisioning  and  nonprovisioning  outgoing  SSR  transac¬ 
tions. 

(5)  Outgoing  Advice  Transactions.  These  are  man¬ 
ually  generated  advice  transactions  including  advices  to  incoming 
SSR  transactions  from  SICCs  and  offer  replies  to  offer  advice 
transactions  from  IMMs. 

(6)  Incoming  SSR  Transactions.  These  are  transac¬ 
tions  submitted  to  an  Air  Force  ALC  as  a  WIMM  and  include  provi¬ 
sioning  and  nonprovisioning  SSR  transactions. 

(7)  Incoming  Advice  Transactions.  These  are  trans¬ 
actions  providing  advice  tq--  the  Air  Force  as  the  SICC,  followup 
transactions  to  the  Air  Foirce  as  WIMM  and  Offer  Reply  Transac¬ 
tions  to  the  Air  Force  as  WIMM. 

(8)  Local  Interrogations.  These  are  transactions 
to  extract  selected  data  from  the  SSR  Suspense  File  or  to  per¬ 
form  file  maintenance  on  that  file. 

b.  Files  .  There  are  five  files  associated  with  this 
application.  These  are  the  Positive  NSN  Table  File,  the  MOE 
Rule  Table  File,  the  SSR  Suspense  File,  the  Local  Catalog 
Suspense  File  and  the  DLSC  Suspense  File. 

(1)  Positive  NSN  Table  File.  This  magnetic  tape 
file  contains  all  NSNs  for  which  an  accept  advice  has  been 
received  by  an  ALC  within  the  last  two  years.  This  file  is 
automatically  updated  by  the  SSR  Application  in  the  Monthly 
Processing  Phase. 
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( 2 )  Major  Organizational  Entity  (MOE)  Rule  Table 
File .  This  is  a  magnetic  tape  file  in  MOE  Rule  sequence  used  to 
determine  the  Primary  Inventory  Control  Activity  (PICA),  Secondary 
Inventory  Control  Activity,  (SICA),  and  Level  of  Authority  (LOA) 
from  DLSC  screening  results. 

(3)  SSR  Suspense  File.  This  magnetic  tape  file  acts 
as  an  active  suspense  and  history  file  of  valid  SSR  and  advice 
transactions  passing  through  the  SSR  Application.  The  file  is 
accessed  in  a  batched  sequential  mode  and  contains  both  active 
and  completed  LISSR  packages.  Items  are  purged  on  a  monthly 
basis  one  year  from  the  earliest  process  date. 

(4)  Local  Catalog  Suspense  File.  This  magnetic 
tape  file  contains  SSR  transactions  for  which  local  file  inter¬ 
rogations  have  been  generated.  SSR  transactions  remain  on  this 
file  for  one  processing  cycle,  after  which  they  are  output  for 
further  processing  regardless  of  whether  or  not  a  reply  was 
received  for  the  item.  Only  SSR  transactions  submitted  with  an 
NSN  are  recorded  on  this  file. 


(5)  DLSC  Suspense  File.  This  magnetic  tape  file 
contains  SSR  transactions  for  which  DLSC  interrogations  are 
generated.  This  file  suspenses  these  items  seven  days,  or  until 
a  DLSC  reply  is  received,  whichever  is  shorter. 


c .  Processing 

Outgoing  and  incoming  provisioning  and  nonprovision¬ 
ing  SSR  transactions  input  to  this  application  are  subjected  to 
an  extensive  validation  process.  Advice  transactions  and  follow¬ 
up  response  transactions  are  validated,  but  to  a  lesser  extent. 
Invalid  outgoing  transactions  are  output  for  functional  correc¬ 
tion  and  reinput.  Invalid  incoming  transactions  have  reject 
advice  transactions  generated  for  return  to  the  SICC.  Valid 
outgoing  SSR  transactions  are  screened  against  DLSC  files  and 
are  examined  against  internal  criteria  to  determine  if  an  SSR 
transaction  will  be  generated.  They  also  have  the  retail  and 
replenishment  quantities  mechanically  computed  when  required. 
Valid  outgoing  and  incoming  SSR  transactions  are  posted  to  the 
SSR  Suspense  File  and  have  cataloging  transactions  generated 
when  appropriate.  Advice  transactions  are  used  to  update  the 
SSR  Suspense  File  and  generate  update  transactions  to  the  provi¬ 
sioning  subsystem.  Various  functional  listings  are  produced. 

Monthly  processing  includes  updating  of  the  Positive 
NSN  Table  File  and  purging  of  the  SSR  Suspense  File.  Various 
functional  reports  and  listings  are  prepared  in  the  monthly  pro¬ 
cessing  cycle . 
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d.  Outputs .  This  subsystem  produces  several  output 
products  as  shown  by  Figure  IV-3. 

(1)  Updated  Positive  NSN  Table  File.  This  file  is 
updated  on  a  monthly  basis.  Items  on  the  SSR  Suspense  File 
which  were  accepted  for  support  by  another  Service  or  Agency  are 
posted  to  the  file.  Items  over  two  years  old  are  deleted  from 
the  file. 


(2)  Updated  SSR  Suspense  File.  This  file  is  up¬ 
dated  on  a  monthly  basis  to  delete  items  which  have  been  on  the 
file  for  one  year.  The  current  date  to  earliest  file  date  is 
used  as  criteria  and  both  active  and  completed  items  are  deleted. 


(3)  Outgoing  Advice/Catalog  Transactions.  The  sub¬ 
system  is  set  up  to  output  these  transactions,  either  to  an  AUTODIN 
tape  for  transmittal,  or  as  punched  cards.  Included  in  these 
transactions  are  outgoing  advice  transactions,  offer  reply  trans¬ 
actions,  followup  response  transactions  and  cataloging  transac¬ 
tions. 


(4)  Outgoing  SSR  Transactions.  These  transactions 
may  be  output  as  punched  cards  or  as  an  AUTODIN  tape  and  includes 
outgoing  provisioning  and  nonprovisioning  SSR  transactions  for  IMM 
action.  Note:  Although  the  systems  design  provides  the  capability 
of  sending  request  transactions  over  AUTODIN,  the  IMM  Manual  re¬ 
quired  the  submission  of  request  transactions  by  mail  while  per¬ 
mitting  advice  transactions  to  be  sent  by  AUTODIN. 

(5)  Local  Catalog  File  Inquiries.  These  are  trans¬ 
actions  for  incoming  SSR  transactions  with  NSNs  to  extract  se¬ 
lected  data  from  a  local  cataloging  file. 

(6)  DLSC  Inquiries  .  These  are  inquiries  from  out¬ 
going  SSR  items  with  or  without  NSNs  to  be  screened  against  DLSC 
files  • 

(7)  Dally  SSR  Functional  Listings.  These  are  func¬ 
tional  outputs  from  the  daily  processing  cycle.  These  will  be 
discussed  in  the  detailed  description  below. 

(8)  Monthly  SSR  Functional  Listings.  These  are 
listings  and  reports  produced  for  functional  use  on  a  monthly 
hasls.  They  will  be  described  in  the  detailed  description  below. 

(9)  Provisioning  Updates.  These  are  transactions 
to  provide  advice  to  the  Provisioning  Subsystem.  This  interface 
between  the  Provisioning  Subsystem  and  SSR  Subsystem  is  described 
in  greater  detail  next. 
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E .  PROVISIONING  SUBSYSTEM/ SSR  SUBSYSTEM  TWO-WAY  INTERFACE 

The  Provisioning  Subsystem  and  the  SSR  Subsystem  were  each 
Initiated  and  designed  separately  by  different  activities  as 
explained  earlier  in  this  Chapter.  During  this  design  process 
it  was  recognized  that  since  the  Provisioning  Subsystem  feeds 
SSR  candidates  to  the  SSR  Subsystem,  there  is  no  reason  why  the 
SSR  Subsystem  could  not  feed  advice  back  to  the  Provisioning 
Subsystem.  To  accommodate  this  Interchange  of  data,  an  inter¬ 
face  agreement  was  developed  by  the  functional  and  automated 
systems  designers  of  both  Subsystems.  This  agreement  is  pre¬ 
sented  separately  due  to  the  uniqueness  of  this  data  interchange 
process.  This  P ro via ioni ng / SSR  two-way  interface  is  illustrated 
in  Figure  I V-4  . 

1.  Phase  I.  The  interface  agreement  is  a  three  phase  pro¬ 
cess  and  each  phase  is  explained  separately.  The  initial  phase 
involves  generation  of  SSR  candidates  by  the  Provisioning  Sub¬ 
system  and  validation  of  these  candidates  by  the  SSR  Subsystem. 

The  Provisioning  Subsystem  selects  SSR  candidate  items  as  dis¬ 
cussed  in  the  Systems  Overview.  These  items  are  formatted  into 
skeleton  SSR  transactions  and  forwarded  to  the  SSR  Subsystem. 

These  items  are  also  placed  on  the  SSR  Candidate  Suspense  File 
under  a  21-day  suspense.  If  21  days  pass  and  a  reply  indicating 
initial  receipt  has  not  been  received  from  the  SSR  Subsystem,  an 
automated  delinquency  followup  is  generated  and  forwarded  to  the 
SSR  Subsystem;  a  delinquency  notice  is  also  printed  for  functional 
notification.  A  followup  will  be  generated  every  21  days  until 
an  initial  receipt  response  is  received.  SSR  candidates  received 
by  the  SSR  Subsystem  are  first  validated  for  format  and  content. 

If  found  to  be  valid,  an  initial  receipt  notification  is  automat¬ 
ically  generated  and  returned  to  the  Provisioning  Subsystem  when 
the  item  is  posted  to  the  SSR  Suspense  File.  If  found  to  be  in¬ 
valid,  no  notification  is  prepared  and  the  invalid  candidates  are 
output  for  functional  correction  and  reinput.  When  the  initial 
receipt  notification  is  received  by  the  Provisioning  Subsystem, 
the  21-day  suspense  is  cleared  from  the  SSR  Candidate  Suspense 
File  and  the  second  phase  of  the  interface  begins. 

2 •  Phase  II 

The  second  phase  places  a  60-day  suspense  on  NSN  items 
and  a  90-day  suspense  on  part  number  items.  This  suspense  also 
continues  through  the  third  phase  of  the  interface  agreement. 

After  items  are  validated  by  the  SSR  Subsystem,  they  are  screened 
against  DLSC  files.  When  this  screening  process  Indicates  a 
preferred  NSN  exists,  the  preferred  NSN  will  be  used  in  the  SSR 
transaction  to  the  IMM  and  is  also  returned  to  the  Provisioning 
Subsystem.  The  Provisioning  Subsystem  will  place  the  preferred 
NSN  on  the  PLISN  Master  File,  but  the  suspense  remains  in  effect. 
When  DLSC  screening  indicates  an  alternate  IMM  for  an  item,  the 


SSR  Subsystem  ceases  processing  on  the  item  and  returns  this  In¬ 
formation  to  the  Provisioning  Subsystem  where  the  suspense  is 
cleared,  a  new  SSR  candidate  is  generated  and  Phase  I  interface 
processing  takes  place.  When  DLSC  screening  indicates  the  item 
is  managed  by  the  Air  Force  or  the  item  is  condemned,  terminal 
or  fabricated,  the  SSR  Subsystem  ceases  processing  and  the  infor¬ 
mation  is  returned  to  the  Provisioning  Subsystem.  The  Provision¬ 
ing  Subsystem  clears  the  suspense  and  takes  action  to  output  the 
item  for  technical  or  item  management  review.  When  the  SSR  Sub¬ 
system  determines  the  Unit  of  Issue  or  Federal  Supply  Code  for 
Manufacturers  or  other  data  is  Incorrect  as  submitted  by  the 
Provisioning  Subsystem,  the  proper  data  will  be  inserted  in  the 
SSR  transactions  to  be  forwarded  to  the  IMM.  The  correct  data 
is  also  forwarded  to  the  Provisioning  Subsystem  where  the  suspense 
remains  in  effect  and  the  data  replaces  Incorrect  data  in  the 
PLISN  Master  File.  When  the  SSR  Subsystem  determines  that  accept 
advice  has  been  received  for  an  item  within  the  past  two  years, 
and  the  extended  dollar  value  of  the  SSR  is  less  than  $1,000, 

SSR  Subsystem  processing  ceases  and  this  information  is  passed 
to  the  Provisioning  Subsystem.  The  Provisioning  Subsystem  con¬ 
siders  this  accept  advice  and  clears  the  suspense  on  these  items. 
No  further  action  is  taken  on  these  items  in  the  SSR  Subsystem. 

When  the  suspense  established  by  the  Provisioning  Sub¬ 
system  is  reached,  an  automated  delinquency  followup  is  generated 
and  forwarded  to  the  SSR  Subsystem.  A  delinquency  notice  is  also 
output  for  functional  notification.  The  SSR  Subsystem  must  reply 
to  this  followup  within  ten  days  or  another  followup  will  be 
generated  then  and  every  ten  days  thereafter  until  a  reply  is 
received.  The  SSR  Subsystem  replies  to  a  followup  in  one  of  three 
ways  based  on  information  available  in  the  SSR  Suspense  File. 

An  interim  IMM  advice  is  returned  to  the  Provisioning  Subsystem, 
or  a  reply  is  given  indicating  IMM  advice  has  not  yet  been  re¬ 
ceived,  or  a  No  Record  Advice  is  returned  on  the  item.  When  an 
SSR  item  is  delayed  in  processing  the  functional  user  may  gener¬ 
ate  an  advice  to  the  Provisioning  Subsystem  indicating  the  reason 
for  delay  will  be  forwarded  as  hardcopy.  When  a  No  Record  Reply 
is  received  by  the  Provisioning  Subsystem,  a  new  SSR  candidate 
is  generated  and  the  interface  processing  begins  again  at  Phase 
I,  otherwise  the  suspense  is  reestablished. 

3.  Pha  s e  III.  The  third  and  final  phase  involves  return  of 
final  IMM  advice  to  the  Provisioning  Subsystem  by  the  SSR  Sub¬ 
system.  When  advice  is  received  by  the  SSR  Subsystem  from  the 
IMM,  it  is  forwarded  to  the  Provisioning  Subsystem.  All  advices 
except  those  returning  a  preferred,  superseding,  standard,  dupli¬ 
cate  item  NSN,  substitute  Part  Number,  or  standard  PSCN  clear 
the  suspense  and  update  the  PLISN  Master  File;  the  latter  types 
of  advice  update  the  PLISN  Master  File,  but  retain  the  suspense. 
Based  on  the  advice  received,  the  Provisioning  Subsystem  initiates 
further  actions  as  necessary. 
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F. 


DETAILED  DAILY  SSR  APPLICATION  DESCRIPTION 


The  Air  Force  Daily  SSR  Application  was  designed  and  devel¬ 
oped  to  include  nine  program  modules  as  shown  in  Figure  IV-5. 

These  program  modules  are  Append  Sort  Key,  SSR  Validation,  Ex¬ 
tract  MOE  Rule  Data,  DLSC  Provisioning  Screening,  Local  Catalog 
File  Screening,  SSR  Transaction  Determination,  SSR  File  Mainte¬ 
nance,  SSR  Card  Generator  and  SSR  List:  Generator.  Each  of  these 
program  modules  is  discussed  in  terms  of  its  inputs,  files,  pro¬ 
cessing  and  outputs  in  this  paragraph.  The  Daily  SSR  Application 
is  a  detailed  breakdown  of  the  portion  of  the  SSR  Subsystem  shown 
in  Figure  IV-3  dealing  with  daily  processing. 

The  program  modules  shown  in  Figure  IV-5  are  generally  sched¬ 
uled  in  a  single  job  stream.  Processing  is  accomplished  in  a 
batched  sequential  operating  mode.  Although  this  application  is 
termed  a  daily  application  by  the  Air  Force,  it  is  generally  not 
executed  on  a  daily  basis  at  the  ALCs .  The  Functional  Descrip¬ 
tion  specifies  this  application  be  executed  a  minimum  of  twice 
per  week . 

As  illustrated  by  Figure  IV-4,  this  application  is  designed 
to  process  incoming  and  outgoing  provisioning  and  nonprovisioning 
SSR  transactions  in  addition  to  incoming  and  outgoing  advice 
transactions.  One  feature  of  this  application  is  the  assignment 
of  Type  Change  Code  (TCC)  'V'  for  outgoing  nonprovisioning  SSR 
transactions  based  on  the  PCC  contained  in  each  transaction. 

This  action  is  accomplished  in  the  SSR  File  Maintenance  Program 
Module  by  matching  the  PCC  of  the  SSR  transaction  against  a  PCC 
table  that  is  internal  to  the  program  module.  When  a  match  occurs, 
TCC  'V'  is  inserted  in  the  SSR  transaction. 

I .  Append  Sort  Key 

a.  Inputs.  Inputs  to  this  program  module  include  screen¬ 
ing  replies,  SSR  candidates  from  the  automated  provisioning  sub¬ 
system,  manually  generated  provisioning  and  no.nprovisioning  SSR 
transactions,  outgoing  advice  transactions,  Incoming  SSR  trans¬ 
actions,  Incoming  advice  transactions  and  local  functional  inter- 
rogat  ions  . 


(1)  DLSC  Replies .  These  are  transactions  replying 
to  DLSC  screening  inquiries  generated  by  this  application. 

(2)  Local  Catalog  File  Replies.  These  are  transac¬ 
tions  replying  to  local  catalog  file  screening  inquiries. 

(3)  SSR  Candidates .  These  are  skeleton  SSR  trans¬ 
actions  generated  by  the  automated  provisioning  subsystem  and 
forwarded  to  this  application  for  further  processing. 
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figure  IV- 


(4)  Outgoing  SSR  Transactions .  These  are  manually 
generated  outgoing  provisioning  and  nonprovisioning  SSR  transac¬ 
tions  . 

(5)  Outgoing  Advice  Transactions.  These  are  man¬ 
ually  generated  advice  transactions  including  accept  advice 
transactions,  reject  advice  transactions,  offer  advice  transac¬ 
tions,  NSN  Notification  transactions  and  followup  response  trans¬ 
actions  to  reply  to  incoming  S.SR  transactions  and  followups. 

These  transactions  also  include  offer  re  ply  transactions  to  re¬ 
spond  to  incoming  offer  advice  transactions. 

(6)  Incoming  SSR  Transactions.  These  transactions 
include  provisioning  and  nonprovisioning  SSR  transactions  sub¬ 
mitted  to  the  ALC  as  a  WIMM. 

(7)  Incoming  Advice:  Transactions.  These  transac¬ 
tions  may  be  received  by  mail  or  AUTODIN  and  include  accept 
advice  transactions,  reject  advice  transactions,  offer  advice 
transactions,  NSN  Notifications  and  followup  response  transac¬ 
tions  to  reply  to  outgoing  SSR  transactions  and  followup  trans¬ 
actions  generated  by  the  ALC.  These  transactions  also  include 
incoming  followup  transactions  and  offer  reply  transactions  from 
SICCs. 

(8)  Local  Functional  Interrogations.  These  are 
transactions  to  update  or  request  information  from  the  SSR 
Suspense  File . 

b.  Files .  No  files  are  accessed  by  this  program 

module  . 

c.  Processing .  This  program  module  expands  each  input 
transaction  to  150  characters.  A  sort  key  is  built  into  posi¬ 
tions  100-122  of  each  transaction.  Input  transactions  enter  in 
random  sequence  and  are  processed  in  that  manner.  No  transac¬ 
tions  are  added  or  deleted  by  this  program  module.  The  sort  key 
built  for  SSR  transactions  and  advice  transactions  is  shown 
below. 


ta  Element 

Sequence 

Character 

Positions 

PCC 

1 

100-102 

ISN 

2 

103-108 

Document  Number 

3 

109-112 

Process  Date 

4 

113-117 

DIC 

5 

118-120 

TCC 

6 

121 

Card  Number 

7 

122 
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The  Document  Number  is  assigned  by  a  functional  user  for  outgoing 
S SR  transactions;  incoming  SSR  transactions  and  advice  transac¬ 
tions  use  the  DOR  instead  of  this  Document  Number.  The  process 
dat  is  added  by  the  application  as  a  computer  generated  pro- 
ces  i.ng  date.  Generally  the  SSR/Advice  Transaction  File  is  sorted 
on  this  Sort  Key  prior  to  processing  by  each  of  the  program 
modules  in  this  application. 

d.  Outputs  .  Outputs  from  this  program  module  include 
DLSC  Replies"^  SSR/Advice  Transactions,  and  Input  SSR/Advice 
Transactions  . 

(1)  DLSC  Re  plies .  These  are  the  DLSC  reply  trans¬ 
actions  input  to  this  program  module  in  the  expanded  format. 

(2)  SSR/Advice  Transactions  .  These  transactions 
include  all  transactions  input  to  the  program  module  except  DLSC 
replies  in  the  expanded  format. 

(3)  Input  SSR/Advice  Transactions.  This  magnetic 
tape  contains  a  duplicate  of  every  fS S R  transaction  and  advice 
transaction  input  to  this  application.  This  tape  is  used  later 
in  the  application  to  produce  functional  listings  as  illustrated 
by  Figure  IV-5. 

2.  Extract  MOE  RULE  Data.  This  program  module  may  be  exe¬ 
cuted  concurrently,  or  before  or  after  the  SSR  Validation  Program 
Module  discussed  below. 

a.  Inputs .  Input  to  this  program  module  consists  of 
DLSC  replies  to  screening  requests. 

b.  Files .  The  MOE  Rule  Table  File  is  accessed  by  this 
program  module. 

c.  Processing.  The  DLSC  replies  are  first  sorted  into 
MOE  Rule  sequence  by  the  program  module.  They  are  then  matched 
to  the  MOE  Rule  Table  File  to  extract  the  Primary  Inventory 
Control  Activity  (PICA),  the  PICA  Level  of  Authority  (LOA),  the 
Secondary  Inventory  Control  Activity  (SICA)  and  the  SICA  LOA. 

These  four  data  elements  are  lodged  in  each  DLSC  reply  transac¬ 
tion  by  this  program  module. 

d .  Output .  Output  from  this  program  module  consists  of 
DLSC  replies  updated  with  MOE  Rule  data. 

3 .  SSR  Validation 

a.  Inputs .  The  single  input  to  this  program  module  is 
the  SSR/Advice  Transactions  File  as  shown  in  Figure  IV-5.  Trans¬ 
actions  on  this  file  include  Local  Catalog  File  Replies,  automat¬ 
ically  and  manually  generated  SSR  transactions,  advice  transac¬ 
tions  and  local  functional  file  maintenance  and  interrogation 
transactions  . 
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b. 


Files.  No  files  are  accessed  by  this  program  module. 


Processing 


Input  transactions  are  first  sorted  using  the  sort 
key  established  by  the  Append  Sort  Key  Program  Module.  Local 
Catalog  File  Replies  and  local  functional  file  maintenance  and 
interrogation  transactions  when  encountered  are  simply  passed  to 
the  SSR/Advice  Transactions  File. 


SSR  transactions  and  advice  transactions  are  sub¬ 
jected  to  extensive  validation  by  this  program  module.  Outgoing 
and  incoming  SSR  transactions  are  validated  for  exact  duplicates 
and  valid  LISSR  packages  in  addition  to  detail  data  element  vali¬ 
dation.  Specific  validation  criteria  is  discussed  in  Volume  III. 
These  transactions  are  validated  for  multiple  errors  (maximum  of 
6).  Internal  Air  Force  error  codes  are  appended  to  outgoing  SSR 
transactions,  while  standard  IMM  Manual  error  codes  are  appended 
to  incoming  SSR  transactions.  A  reject  advice  transaction  con¬ 
taining  a  reject  code  indicating  the  first  error  encountered  is 
automatically  generated  for  each  incoming  SSR  transaction  in 
error. 


Advice  transactions  are  validated  for  valid  data  ele¬ 
ment  entries  and  exact  duplicates  by  this  program  module.  Both 
incoming  and  outgoing  advice  transactions  are  validated  only 
until  the  first  error  is  encountered.  At  this  point,  a  reject 
code  is  assigned  to  each  transaction  before  being  output  to  the 
SSR/Advice  Transactions  File. 

d.  Outputs.  The  single  output  from  this  program  module 
is  the  SSR/Advice  Transactions  File.  This  file  contains  all 
transactions  input  to  this  program  module  as  well  as  the  reject 
advice  transactions  generated  by  this  program  module. 

4 .  DLSC  Provisioning  Screening 

a.  Inputs .  There  are  two  inputs  to  this  program 
module,  the  DLSC  Replies  File  and  the  SSR/Advice  Transactions 
File  . 


(1)  DLSC  Replies  File.  These  are  transactions  from 
the  Extract  MOE  Rule  Data  Program  Module. 

(2)  SSR/Advice  Transactions  File.  These  are  trans¬ 
actions  from  the  SSR  Validation  Program  Module. 

b.  Files  .  The  DLSC  Suspense  File  is  accessed  by  this 
program  module.  This  file  contains  valid  outgoing  SSR  transac¬ 
tions  for  which  a  DLSC  screening  inquiry  was  generated  by  this 
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program  module.  These  transactions  remain  on  this  file  until  a 
DLSC  reply  is  received  or  seven  days  whichever  is  shorter.  After 
the  seven  days  have  elapsed  and  no  reply  is  received  the  trans¬ 
action  is  extracted  from  the  DLSC  Suspense  File  for  further  pro¬ 
cessing.  A  followup  DLSC  screening  inquiry  is  not  generated. 

c .  Processing 


DLSC  reply  transactions  are  matched  against  the  DLSC 
Suspense  File.  When  a  match  is  found,  the  NSN,  Unit  of  Issue, 
Acquisition  Advice  Code  and  PICA  from  the  DLSC  reply  is  compared 
against  those  of  the  SSR  transaction  in  the  DLSC  Suspense  File. 
This  may  result  in  a  change  to  a  data  element  in  the  SSR  trans¬ 
action  (e.g.,  a  change  to  unit  of  issue)  or  it  may  result  in  a 
change  to  the  status  of  the  SSR  transaction  (e.g.,  if  AAC  indi¬ 
cates  an  SSR  item  is  terminal,  status  will  change  from  valid  to 
invalid).  Both  the  updated  SSR  transactions  and  the  DLSC  screen¬ 
ing  replies  are  output  to  the  SSR/Advice  Transactions  File.  If 
no  match  is  found  on  the  DLSC  Suspense  File  for  a  DLSC  reply, 
the  reply  is  output  to  the  SSR/Advice  Transactions  File.  These 
DLSC  replies  are  used  later  in  the  application  to  produce  a 
functional  list. 

Only  Valid  Outgoing  SSR  transactions  from  the  input 
SSR/Advice  Transactions  File  are  acted  upon  by  this  program 
module;  all  other  input  transactions  from  this  file  are  output 
directly  to  the  SSR/Advice  Transactions  File.  Valid  outgoing 
SSR  Transactions  have  a  suspense  date  established  and  are  output 
to  the  New  DLSC  Suspense  File  to  await  a  reply  from  DLSC  screen¬ 
ing  inquiries  generated  by  this  program  module  for  these  items. 
DLSC  screening  inquiries  are  generated  for  NSN,  PSCN,  and  Part 
Number  SSR  items. 

d.  Outputs .  There  are  three  outputs  from  this  program 
module;  a  new  DLSC  Suspense  File,  a  DLSC  Inquiries  File  and  the 
SSR/Advice  Transactions  File. 


(1)  New  DLSC  Suspense  File.  This  file  replaces  the 
DLSC  Suspense  File  used  by  this  program  module.  The  new  file  is 
used  in  the  next  processing  cycle. 

(2)  DLSC  Inquiries  File.  This  file  contains  DLSC 
Screening  Inquiries  for  transmittal  to  DLSC. 

(3)  SSR/Advice  Transactions  File.  This  file  con¬ 
tains  transactions  for  further  processing  in  the  next  program 
module  . 
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5 .  Local  Catalog  File  Screen 

a.  Inputs  .  The  single  input  to  this  program  module  is 
the  SSR/Advice  Transactions  File  from  the  previous  program 
module  . 


b .  Files.  The  Local  Catalog  Suspense  File  is  used  by 
this  program  module. 

c .  Processing 


At  this  point  in  the  Daily  SSR  Application,  there 
are  a  multitude  of  different  types  of  transactions  on  the  SSR/ 
Advice  Transactions  File.  This  program  module  takes  action  only 
on  two  types:  Local  Catalog  File  Replies  and  valid  incoming  SSR 
transactions  containing  an  NSN. 

Local  Catalog  File  Replies  are  matched  by  NSN  to  the 
Local  Catalog  Suspense  File.  When  a  match  is  found,  the  Item 
Manager  Designator  is  placed  on  the  incoming  SSR  transaction 
from  the  Suspense  File.  The  SSR  transaction  is  output  to  the 
SSR/Advice  Transactions  File.  The  Local  Catalog  File  Reply  is 
eliminated  from  further  processing.  The  Item  Manager  Designator 
is  an  Air  Force  unique  code  used  to  identify  the  particular  Item 
Manager  responsible  for  management  of  the  item.  Functionally, 
this  is  used  to  route  these  incoming  SSR  transactions  directly 
to  the  appropriate  item  manager.  Local  Catalog  File  Replies 
which  do  not  match  a  suspense  file  record  are  bypassed.  Incom¬ 
ing  SSR  transactions  on  the  suspense  file  for  which  a  Local  Cata¬ 
log  File  reply  is  not  received  do  not  remain  on  the  suspense 
file;  they  are  output  to  the  SSR/Advice  Transactions  File  for 
further  processing. 

Valid  Incoming  SSR  transactions  containing  an  NSN 
which  enter  this  program  module  from  the  input  SSR/Advice  Trans¬ 
actions  File  are  placed  on  the  New  Local  Catalog  Suspense  File 
which  replaces  the  one  accessed  by  this  program  module  In  the 
next  processing  cycle.  An  inquiry  for  each  of  these  incoming 
SSR  transactions  is  formatted  and  output  to  the  Local  Catalog 
File  Inquiries  File  shown  on  Figure  IV-5.  This  Inquiry  Trans¬ 
action  File  Is  passed  to  another  application  which  screens  these 
items  against  a  local  cataloging  file. 

d.  Outputs .  There  are  three  outputs  from  this  program 
module;  a  New  Local  Catalog  Suspense  File,  a  Local  Catalog  File 
Inquiry  Transaction  File  and  the  SSR/Advice  Transactions  File. 

(1)  New  Local  Catalog  Suspense  File.  This  file 
contains  incoming  SSR  transactions  for  which  local  cataloging 
file  screening  transactions  were  generated  by  this  program 
module.  This  file  will  be  used  in  the  next  processing  cycle  of 
this  application. 
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( 2 )  Local  Catalog  File  Inquiry  Transaction  File. 
This  transaction  file  is  passed  to  another  application  for  pro¬ 
cessing  against  a  local  cataloging  file. 

(3)  SSR/Advice  Transactions  File.  This  transaction 
file  contains  items  for  further  processing. 

6.  SSR  Transaction  Determination 


a.  Inputs .  The  single  input  to  this  program  module  is 
the  SSR/Advice  Transactions  File  from  the  previous  program  module. 

b.  Files .  The  Positive  NSN  Table  File  accessed  by  this 
program  module  is  a  sequential  file  based  on  NSN  and  contains 
items  which  have  received  accept  advice  from  an  IMM  within  the 
past  two  years  by  any  of  the  Air  Force  ALCs  . 

c.  Processing .  This  program  module  takes  action  only 
on  valid  outgoing  SSR  transactions;  all  other  transactions  are 
passed  directly  from  the  input  file  to  the  output  file.  Valid 
outgoing  SSR  transactions  containing  an  NSN  are  matched  against 
the  Positive  NSN  Table  File.  When  a  match  occurs,  the  extended 
dollar  value  (unit  price  multiplied  by  the  sum  of  the  retail  and 
replenishment  quantities)  is  computed.  If  this  extended  dollar 
value  is  less  than  or  equal  to  $1,000,  a  code  is  placed  in  the 
transaction  to  indicate  this  situation.  Outgoing  SSR  cards  are 
not  generated  for  these  items.  The  extended  dollar  value  is 
computed  for  all  outgoing  SSR  transaction  input  to  this  program 
module.  When  the  extended  dollar  value  is  greater  than  $1,000, 
the  item  is  output  on  a  functional  list  for  review  to  determine 
if  SSR  transactions  for  these  items  are  to  be  sent  to  the  IMM. 
Outgoing  SSR  cards  are  not  generated  for  these  items  in  the 
current  processing  cycle.  After  a  manual  review  is  made,  new 
transactions  must  be  entered  to  this  application  to  produce  the 
cards  to  be  mailed  to  the  IMMs. 

d.  Outputs .  The  only  output  from  this  program  module 
is  the  SSR/Advice  Transactions  File  which  is  passed  to  the  next 
program  module  for  further  processing. 

7.  SSR  File  Maintenance 


a.  Inputs  .  The  single  input  to  this  program  module  is 
the  SSR/Advice  Transaction  File  from  the  previous  program  module. 
At  this  point  in  the  processing  cycle  this  file  contains  the 
types  of  transactions  listed  below. 

*  Outgoing  SSR  Transactions. 

*  Incoming  SSR  Transactions. 

*  Outgoing  Advice  Transactions. 
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*  Incoming  Advice  Transactions. 

*  DLSC  Reply  Transactions. 

*  Local  Functional  interrogations  and  file 
maintenance  transactions. 


b.  Files .  The  single  file  accessed  by  this  program 
module  is  the  SSR  Suspense  File.  This  file  acts  as  an  opera¬ 
tional,  suspense  and  history  file  for  SSR  processing.  The  file 
resides  on  magnetic  tape  and  consists  of  fixed  length,  150-charac¬ 
ter  records,  sequenced  on  the  sort  key  established  in  the  Append 
Sort  Key  Program  Module.  Only  valid  transactions  are  posted  to 
this  file.  The  types  of  transactions  posted  to  this  file 
include : 


*  PDSSR  Transactions. 

*  LISSR  Transactions. 

*  Item  Name  Transactions. 

*  Additional  Reference  Number  Transactions. 

*  Additional  User  Transactions. 

*  Ac ce p t /Of f e r / Re jec t / NSN  Notification 
Advice  Transactions. 

*  Offer  Reply  Transactions. 

*  Followup  Response  Transactions  (Outgoing 
SSRs  Only) 

*  Provisioning/SSR  Subsystem  Interface 
Transac  tions  . 

The  structure  of  SSR/Advice  records  on  this  file  is 
based  on  the  SSR  transaction  format.  The  first  80  positions  of 
each  SSR  Suspense  File  record  is  a  card  image  of  the  SSR/Advice 
transaction.  Positions  100-122.  contain  a  sort  key  to  sequence 
the  file.  The  remaining  positions  of  each  150  character  record 
are  either  blank  or  contain  internal  Air  Force  data.  The  Air 
Force  uses  an  additional  Program  Data  transaction  to  record  data 
for  internal  Air  Force  use  on  the  SSR  Suspense  File.  This  trans¬ 
action  is  not  output  for  transmittal  to  the  IMMs  and  is  tied  to 
a  PDSSR  transaction  through  the  PCC  located  In  the  Sort  Key. 
Provisioning/SSR  Subsystem  Interface  Transactions  are  also  re¬ 
corded  on  the  SSR  Suspense  File  and  are  tied  to  the  LISSR  trans¬ 
action  to  which  they  apply  through  the  PCC,  ISN,  and  Document 
Number  in  the  Sort  Key. 

c.  Processing .  As  indicated  in  the  Inputs  subparagraph 
above,  there  are  several  types  of  transactions  input  to  this 
program  module.  Each  of  these  transaction  types  is  processed 
differently  by  this  program  module  and,  therefore,  each  is  dis¬ 
cussed  separately. 


109 


( 1 )  Outgoing  Provisioning  and  Nonprovisioning  SSR 


Transactions 


These  transactions  fall  Into  two  groups  for  pro¬ 
cessing.  One  group  contains  valid  transactions,  the  other  con¬ 
tains  Invalid  transactions  and  transactions  which  matched  an  NSN 
on  the  Positive  NSN  Table  File.  Invalid  transactions  are  output 
to  the  print  records  file.  Valid  transactions  which  matched  an 
NSN  on  the  Positive  NSN  Table  File  are  posted  to  the  SSR  Suspense 
File  and  output  to  the  Print  Records  File. 

Valid  transactions  are  first  checked  for  proper 
PCC  package  format  (PDSSR  transaction  with  one  or  more  LISSR 
transactions).  If  a  LISSR  transaction  is  encountered  without  a 
PDSSR  transaction,  the  SSR  Suspense  File  is  searched.  When  a 
PDSSR  with  matching  PCC  is  found  on  the  SSR  Suspense  File,  a 
PDSSR  transaction  is  generated  to  accompany  the  LISSR  transac¬ 
tions.  When  a  matching  PDSSR  transaction  Is  not  located,  the 
LISSR  transaction  becomes  invalid  and  is  output  to  the  print 
records  file.  For  those  transactions  which  pass  the  PCC  package 
check,  the  process  date  is  inserted  as  the  DOR  and  each  LISSR  is 
scanned  to  determine  If  the  retail  and  replenishment  quantities 
must  be  computed.  When  the  retail  quantity  in  the  LISSR  trans¬ 
action  contains  all  blanks  or  is  numeric  and  the  replenishment 
quantity  contains  an  A,  J,  or  X  in  the  first  position,  the  SSR 
quantities  are  computed  by  this  program  module  using  computation 
factors  in  the  SSR  transaction  or  computation  factors  built  into 
the  program  module.  The  computed  quantities  are  inserted  in  the 
LISSR  transaction  before  it  is  posted  to  the  updated  SSR  Suspense 
File.  These  SSR  transactions  are  output  to  the  SSR  Transactions 
File  and  the  print  records  file. 

(2)  Incoming  Provisioning  and  Nonprovisioning  SSR 

Transactions 


These  transactions  also  fall  into  two  groups 
for  processing;  valid  transactions  and  invalid  transactions. 
Invalid  transactions  are  output  to  the  print  records  file  without 
further  processing. 

Valid  transactions  are  subjected  to  the  PCC 
package  check.  Transactions  failing  this  package  check  are  out¬ 
put  on  the  print  records  file.  Transactions  which  pass  the  PCC 
package  check  are  posted  to  the  SSR  Suspense  File  and  output  to 
the  print  records  file. 

(3)  Outgoing  Advice  Transactions.  These  transac¬ 
tions  fall  into  one  of  seven  categories:  Valid  Accept/NSN 
Notification  Advice  Transactions,  Valid  Offer  Advice  Transactions, 
Valid  Reject  Advice  Transactions,  Valid  Offer  Reply  Transactions, 
External  Followup  Transactions,  Followup  Response  Transactions 
and  Invalid  Transactions. 
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actions .  These  transactions  are  first  matched  against  the  SSR 
Suspense  File  based  on  PCC,  ISN,  and  Document  Number.  If  a  match 
ing  LISSR  is  not  found,  the  transaction  becomes  invalid  and  is 
processed  as  other  invalid  transactions  within  this  transaction 
type.  When  a  matching  LISSR  transaction  is  found,  the  advice 
transaction  remains  valid  and  is  posted  to  the  SSR  Suspense 
File.  These  valid  transactions  are  used  to  generate  cataloging 
transactions.  The  cataloging  transactions  and  advice  transac¬ 
tions  are  output  to  the  print  records  file  and  the  Ad v  ice /Ca t a  log 
Transaction  File. 

(b)  Valid  Offer  Advice  Transactions.  These 
transactions  are  checked  against  the  SSR  Suspense  File  for  a 
matching  LISSR  based  on  PCC,  ISN,  Document  Number  and,  if  not 
found,  they  become  invalid  transactions.  Transactions  for  which 
a  matching  LISSR  is  found  are  posted  to  the  SSR  Suspense  File 
and  output  to  the  Print  Records  File  and  the  Ad v ice /Ca t a  1 og  Trans 
action  File.  This  program  module  establishes  a  60-day  suspense 
for  return  of  an  offer  reply  and  if  not  received,  a  reject  advice 
transaction  containing  ATC  '08'  (no  reply  to  offer)  is  automat¬ 
ically  generated  and  output  to  the  Print  Records  File  and  the 

Ad vi c e /Ca t a lo g  Transaction  File. 

(c)  Valid  Reject  Advice  Transactions.  Valid 
reject  advice  transactions  are  posted  to  the  SSR  Suspense  File 
and  output  to  the  Print  Records  File  and  the  Ad  vice /Catalog 
Transaction  File. 

(d)  Valid  Offer  Reply  Transactions.  These 
transactions  are  matched  tc  a  LISSR  on  the  SSR  Suspense  File 
based  on  PCC,  ISN,  and  Document  Number.  If  no  match  is  found 
the  transaction  becomes  invalid  and  is  processed  as  other  inva¬ 
lid  transactions  of  this  type.  Transactions  which  match  a  LISSR 
transaction  are  posted  to  the  SSR  Suspense  File  and  output  to 
the  Print  Records  File  and  the  Ad v ic e / Ca t a log  Transaction  File. 
When  the  matched  LISSR  originated  in  the  automated  provisioning 
subsystem  and  the  offer  reply  is  accepting  an  offer,  an  update 
transaction  is  generated  and  output  to  the  Provisioning  Updates 
File. 

(e)  Followup  Transactions  (External).  These 
transactions  are  automatically  generated  by  this  program  module. 
When  an  outgoing  SSR  transaction  is  posted  to  the  SSR  Suspense 
File  and  output  for  transmittal  to  an  IMM,  a  suspense  is  placed 
on  the  item.  SSR  transactions  containing  an  NSN  have  a  40-day 
suspense  placed  on  the  item;  SSR  transactions  containing  a  Part 
Number  have  a  75-day  suspense.  If  an  advice  transaction  is  not 
received  within  the  suspense  time,  a  followup  transaction  is 
generated.  After  a  first  followup  transaction,  additional  fol¬ 
lowup  transactions  will  be  generated  on  a  60-day  cycle  until 


advice  ia  received  from  the  IMM.  The  followup  transactions  are 
output  to  the  Print  Record  File  and  the  Advice/  Catalog  Transac¬ 
tions  File. 


(f)  Followup  Response  Transactions.  These 
transactions  are  automatically  generated  upon  receipt  of  a  follow¬ 
up  transaction.  These  transactions  are  output  to  the  Print 
Records  File  and  the  Ad v ice / Ca t a  log  Transaction  File. 

( g )  Invalid  Outgoing  Advice  Transactions. 

These  transactions  are  output  directly  to  the  Print  Records  File. 

(4)  Incoming  Advice  Transactions.  These  transac¬ 
tions  fall  into  one  of  the  same  seven  categories  discussed  under 
Outgoing  Advice  Transactions  above.  Each  category  is  discussed 
separately  here  as  above. 

( a )  Valid  Accept/NSN  Notification  Advice  Trans¬ 
actions  .  These  transactions  are  first  matched  against  the  SSR 
Suspense  File  based  on  PCC,  ISN,  DOR.  If  a  matching  LISSR  is  not 
found,  they  become  invalid  and  are  handled  as  any  other  Invalid 
transaction  of  this  type.  Transactions  for  which  a  match  is 
found  are  posted  to  the  Updated  SSR  Suspense  File  and  output  to 
the  Print  Records  File.  When  the  matching  LISSR  was  generated 

by  the  automated  provisioning  subsystem,  a  transaction  is  gener¬ 
ated  and  output  to  the  Provisioning  Updates  File  to  provide  the 
advice  to  the  Provisioning  Subsystem.  These  transactions  are 
also  posted  to  the  Updated  SSR  Suspense  File.  Cataloging  trans¬ 
actions  are  also  generated  when  these  transactions  are  received 
and  are  output  to  the  Ad v i ce / Cat a lo g  Transaction  File. 

(b)  Valid  Offer  Advice  Transactions.  Valid 
offer  advice  transactions  are  matched  to  the  SSR  Suspense  File 
based  on  PCC,  ISN,  DOR.  If  a  matching  LISSR  transaction  is  not 
found,  the  offer  advice  transaction  becomes  Invalid  and  is  pro¬ 
cessed  as  any  other  invalid  transaction  within  this  type.  When 
a  match  is  found  the  Offer  Advice  Transaction  Is  posted  to  the 
SSR  Suspense  File  and  output  to  the  Print  Records  File. 

(c)  Valid  Reject  Advice  Transactions.  These 
transactions  are  matched  to  the  SSR  Suspense  File  based  on  PCC, 
ISN,  and  DOR.  If  no  matching  LISSR  transaction  is  found,  the 
transaction  becomes  invalid  and  is  processed  as  any  other  invalid 
transaction  of  this  type.  Transactions  that  match  to  a  LISSR  on 
the  SSR  Suspense  File  are  posted  to  the  Updated  SSR  Suspense 
File  and  output  to  the  Print  Records  File.  When  the  ATC  on  the 
reject  transaction  is  one  of  those  listed  below,  a  new  LISSR 
transaction  is  automatically  generated  from  the  LISSR  transac¬ 
tion  on  the  SSR  Suspense  File  and  the  Reject  Advice  Transaction. 
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YJ  -  NSN  submitted  has  been  superseded. 

YR  -  Item  submitted  is  nonstandard, 
standard  NSN  furnished. 

YW  -  Item  submitted  is  nonstandard, 
standard  PSCN  furnished. 

05  -  Blank  or  invalid  IMC. 

18  -  Invalid  source  code. 

34  -  Item  submitted  matches  to  NSN  in 
DLSC  File,  matched  NSN  furnished. 

08  -  No  reply  to  offer. 

These  new  LISSR  transactions  along  with  a  generated  PDSSR  trans¬ 
action  are  posted  to  the  Updated  SSR  Suspense  File  and  output  to 
the  SSR  Transactions  File  and  the  Print  Records  File. 

(d)  Valid  Offer  Reply  Transactions.  These 
transactions  are  matched  to  the  SSR  Suspense  File  based  on  PCC, 

ISN,  and  DOR.  If  a  matching  LISSR  is  not  found,  the  transaction 
becomes  invalid  and  is  processed  as  any  other  invalid  transac¬ 
tion  of  this  type.  When  the  transaction  matches  to  a  LISSR 
transaction,  the  Offer  Reply  Transaction  is  posted  to  the  SSR 
Suspense  File  and  output  to  the  Print  Records  File.  When  the 
advice  on  the  Offer  Reply  Transaction  is  accept,  cataloging 
transactions  are  automatically  generated  and  output  to  the 

Ad v i ce / Ca t a  log  Transaction  File. 

(e)  Valid  Followup  Transactions.  These  trans¬ 
actions  are  processed  on  a  totally  automated  basis  and  are  never 
reviewed  by  a  functional  user  before  the  followup  response  trans¬ 
action  is  generated  and  forwarded  to  the  SICC.  These  transac¬ 
tions  are  matched  to  the  SSR  Suspense  File  and  a  Followup  Response 
fiaP.  s  action  is  generated  based  on  the  results  of  the  mar'-’  The 
followup  transactions  are  output  to  the  Print  Record  File.  When 

a  followup  transaction  matches  to  one  or  more  transactions  on  the 
SSR  Suspense  File  and  one  of  the  matching  transactions  is  an 
Acce p t / Of f e r / Re jec t / NSN  Notification  Advice  Transactions,  the 
same  advice  is  used  in  the  Followup  Response  Transaction.  When 
a  followup  transaction  matches  to  a  LISSR  on  the  SSR  Suspense 
File  and  no  advice  transaction  resides  on  the  file,  an  advice  of 
'67'  is  used  in  the  Followup  Response  Transaction.  When  a  No 
Match  occurs,  an  advice  of  '66'  (no  record)  is  used  in  the  Follow¬ 
up  Response  Transaction. 

( f )  Valid  Followup  Response  Transactions. 

These  transactions  are  processed  identically  to  Valid  Acce p t /Of f er / 
Reject/NSN  Notification  Advice  Transactions  discussed  above.  A 
reject  advice  of  66  (no  record)  may  be  received  in  this  category 
of  transaction.  When  this  occurs  a  new  SSR  transaction  is  gener¬ 
ated  as  described  for  reject  advices  YJ,  YR,  YW,  05,  18,  34,  and 
08  above. 
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(g)  Invalid  Incoming  Advice  Transactions. 

These  transactions  are  output  directly  to  the  Print  Records  File. 

(5)  DLSC  Reply  Transactions.  These  transactions 
are  output  directly  to  the  Print  Records  File. 

(6)  Local  Functional  Interrogations.  These  transac¬ 
tions  are  matched  to  the  SSR  Suspense  File  based  on  PCC  or  PCC, 
and  ISN.  All  matching  records  are  output  to  the  Print  Records 
File.  When  a  No  Match  occurs  a  No  Match  Transaction  is  generated 
and  output  to  the  Print  Records  File. 

(7)  Local  File  Maintenance  Transactions.  These 
transactions  are  used  to  delete  records  from  the  SSR  Suspense 
File.  Only  delete  actions  are  accomplished  by  file  maintenance 
transactions  .  Deleted  records  are  output  to  the  Print  Records 
File. 


( 8 )  Outgoing  and  Incoming  SSR  Change  Transactions. 
These  are  transactions  containing  changes  to  previously  sub¬ 
mitted  or  received  SSR  transactions.  They  are  validated  as  are 
other  SSR  transactions  input  to  this  application,  but  must  also 
match  to  a  LISSR  transaction  already  on  the  SSR  Suspense  File. 

If  a  no  match  occurs,  the  change  transaction  becomes  invalid. 

Valid  change  transactions  are  posted  to  the  SSR  Suspense  File 
and  output  as  any  other  outgoing  or  incoming  SSR  transaction. 
Invalid  change  transactions  are  output  directly  to  the  Print 
Records  File. 

( 9 )  Internal  Functional  Followups 

There  are  several  internal  system  suspenses  and 
followups  other  than  those  already  discussed.  Internal  functional 
f ollowups  are  generated  for  outgoing  SSR  transactions  which  break 
the  $1,000  limit,  those  on  which  offers  are  received  and  those 
which  are  rejected  by  an  IMM.  Internal  functional  followups  are 
generated  for  incoming  SSR  transactions  which  require  manual 
advice  decision. 


Outgoing  SSR  transactions  which  break  the  ex¬ 
tended  dollar  value  limit  of  $1000  are  placed  on  the  SSR  Suspense 
File  and  output  for  manual  review.  A  15-day  suspense  is  placed 
on  these  items  for  a  response  from  the  functional  user.  When  a 
response  is  not  received  in  the  15  days  allotted,  an  internal 
followup  is  generated  and  output  on  the  Print  Records  File. 

Outgoing  SSR  transactions  which  receive  offer 
advice  from  an  IMM  are  placed  under  a  15-day  suspense  for  offer 
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advice  deteralnatlon  and  return  to  the  1  MM .  When  an  offer  reply 
transaction  has  not  entered  the  SSR  Suspense  File  and  cleared 
this  suspense  within  the  15-day  period,  an  Internal  followup  Is 
generated  and  output  to  the  Print  Records  File. 

Outgoing  SSR  transactions  which  receive  a  reject 
advice  other  than  YJ,  YR,  YW,  05,  18,  34,  08,  and  66  from  an  I  MM 
are  placed  under  a  30-day  suspense  for  resubmlsslon  or  deletion 
action.  When  an  SSR  resubmittal  Is  not  placed  on  the  SSR  Suspense 
File,  or  when  the  Item  is  not  deleted  from  the  SSR  Suspense  File 
within  the  30-day  period,  an  Internal  followup  is  generated  and 
placed  on  the  Print  Records  File. 

Incoming  SSR  transactions  containing  an  NSN  are 
placed  under  a  25-day  suspense  when  they  enter  the  SSR  Suspense 
File.  If  an  advice  transaction  containing  support  advice  does 
not  enter  the  SSR  Suspense  File  within  the  25-day  period  to 
clear  the  suspense,  an  internal  followup  Is  generated  and  output 
to  the  Print  Records  File.  Additional  Internal  followups  will 
be  generated  every  25  days  until  the  suspense  Is  cleared. 

Incoming  SSR  transactions  containing  a  Part 
Number  are  placed  under  a  60-day  suspense  when  they  enter  the 
SSR  Suspense  File.  When  an  advice  transaction  is  not  posted  to 
the  SSR  Suspense  File  to  clear  this  suspense  an  internal  follow¬ 
up  will  be  generated  and  output  to  the  Print  Records  File  after 
60  days.  Additional  internal  followups  will  be  generated  every 
25  days  until  the  suspense  is  cleared. 

d.  Outputs  .  There  are  five  outputs  from  this  program 
module.  These  are  the  Updated  SSR  Suspense  File,  SSR  Transac¬ 
tion  File,  Advice/Catalog  Transactions  File,  Provisioning  Up¬ 
dates  File,  and  Print  Records  File. 

(1)  Updated  SSR  Suspense  File.  This  file  is  used 
to  replace  the  SSR  Suspense  File  used  by  this  program  module. 

It  is  used  In  the  next  dally  processing  cycle  or  In  the  Monthly 
SSR  Application,  whichever  is  executed  first.  It  contains  all 
records  on  the  SSR  Suspense  File  used  by  this  program  module 
except  those  items  deleted  through  file  maintenance  actions.  It 
also  contains  transactions  added  in  the  current  processing 
cycle. 


(2)  SSR  Transactions  File.  This  file  contains  out¬ 
going  provisioning  and  nonprovisioning  SSR  transactions  and  out¬ 
going  SSR  change  transactions  that  are  to  be  mailed  to  an  I  MM . 

(3)  Advice/Catalog  Transactions  File.  This  is  an 
AUTODIN  file  containing  outgoing  advice  transactions  for  trans¬ 
mittal  to  other  activities  and  cataloging  transactions  for  trans¬ 
mittal  to  CASO  for  further  processing.  These  catalog  transactions 
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contain  data  which  is  used  by  CASO  to  update  Air  Force  peculiar 
data  in  DLSC  files  and  to  generate  Add  User  transactions  to  record 
SICCs  as  users  of  Air  Force  managed  items  in  DLSC  files. 


(4)  Provisioning  Updates  File.  This  file  is  input 
to  the  provisioning  subsystem  to  update  provisioning  files  with 
SSR  item  s t a t us / ad v i c e  . 

(5)  Print  Records  File.  This  file  contains  records 
used  to  produce  listings  for  functional  use. 

8 .  SSR  Card  Generator 

a.  Inputs.  The  single  input  to  this  program  module  is 
tlie  SSR  Transactions  File  shown  in  Figure  IV -  5. 

b .  Files .  No  files  are  accessed  by  this  program 

modu  le  . 

c.  Processing.  Processing  in  this  program  module  con¬ 
sists  of  sorting  input  transactions  into  PCC,  DOR,  ACT,  ISN, 

DIC,  rCC ,  and  Card  Number  sequence,  and  punching  each  transac¬ 
tion  on  an  EAM  card.  These  cards  are  interpreted  and  forwarded 
to  the  functional  user  for  mailing  to  the  appropriate  TMMs. 

d.  Outputs .  The  single  output  from  this  program  module 
is  the  outgoing  SSR  cards  for  mailing  to  IMMs. 

9 .  SSR  List  Generator 

a .  I n  p uts .  There  are  two  transaction  files  input  to 
this  program  module;  the  Print  Record  Fill'  and  the  Input  SSR/ 
Advice  Transaction  File. 

h .  Files.  No  files  are  accessed  by  this  program 

m  o  d  u  1  e  . 

c.  Processing.  This  program  module  sorts  records  into 
listing  sequence,  formats  and  edits  each  record  and  prints  each 
of  the  functional  listings  described  below. 

d .  Outputs.  This  program  module  prints  several  listings 
tor  functional  use.  Each  listing  is  Jos  ■  r I  bed  below. 

(1)  Totals  of  Incoming  Advice  Summary.  This  list¬ 
ing  Is  produced  as  the  result  of  a  local  interrogation  and  lists 
reject  advice  codes  by  PCC. 

(2)  DLSC  Screen  Results.  This  is  a  printout  of 
DLSC  reply  transactions  received  as  a  result  of  screening  trans¬ 
actions  generated  by  the  DLSC  Provisioning  Screening  Program 
Module.  A  sample  of  this  listing  is  shown  In  Figure  IV-b. 
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(3)  WIMM  SSR  Advice  List.  This  is  a  listing  of 
outgoing  advice  transactions  responding  to  incoming  SSR  transac¬ 
tions  and  incoming  followup  transactions. 

(4)  Input  Errors.  This  is  a  list  of  all  transac¬ 
tions  found  to  be  invalid  by  this  application.  A  sample  format 
of  this  listing  is  shown  by  Figure  IV-7. 

(5)  Source  SSR/Advice  Input.  This  is  a  list  of  SSR, 
advice  and  file  maintenance  transactions  input  to  this  applica¬ 
tion.  A  sample  format  of  this  listing  is  shown  by  Figure  IV-8. 

(6)  SSR  Suspense  File  Interrogation.  This  list  is 
generated  as  a  result  of  a  local  functional  interrogation  re¬ 
questing  information  from  the  SSR  Suspense  File.  A  sample  of 
this  listing  is  shown  by  Figure  IV-9. 

(7)  SSR  Suspense  File  Deletion.  This  list  is  pro¬ 
duced  as  a  result  of  a  file  maintenance  transaction  deleting 
items  from  the  SSR  Suspense  File.  A  sample  of  this  listing  is 
shown  by  Figure  IV-10. 

(8)  SSR  Accept  Advice  Notice.  This  is  a  list  of 
incoming  accept/NSN  notification  transactions  received  in  the 
current  processing  cycle.  A  sample  of  this  listing  is  shown  in 
Figure  I  V- 1 1 . 


(9)  SSR  Reject  Advice  Notice.  This  is  a  list  of 
incoming  offer/reject  advice  transactions  received  in  the  current 
processing  cycle.  A  sample  of  this  listing  is  shown  in  Figure 
I V- 1 2 . 

(10)  SSR  Items  With  Total  Dollar  Value  Over  $1,000 
for  Review.  This  is  a  listing  of  each  outgoing  SSR  transaction 
input  in  the  current  processing  cycle  having  an  extended  dollar 
value  over  $1,000.  A  sample  of  this  listing  is  shown  in  Figure 
I V- 1 3  . 

(11)  Supply  Support  Request  List.  This  is  a  listing 
of  all  outgoing  SSR  transactions  for  which  SSR  cards  were  output 
by  this  processing  cycle.  A  sample  of  this  report  is  shown  in 

F igure  I V-14 . 

(12)  Reply  to  Supply  Support  Request,  Past  Due. 

This  is  a  list  of  outgoing  SSR  transactions  for  which  no  advice 
has  been  received  from  the  IMMs  within  95  days  for  items  with 
NSNs  and  130  days  for  items  without  NSNs.  A  sample  of  this 
listing  is  shown  in  Figure  IV-15. 
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Figure  IV-15 


(13)  Reply  to  SSR  Advice  Past  Due.  This  listing 
acts  as  an  internal  followup  on  items  for  which  an  offer  or 
reject  advice  was  received  from  an  IMM  and  no  offer  reply  or  SSR 
resubmittal  has  been  posted  to  the  SSR  Suspense  File  to  clear 
the  25/30  day  suspense-  A  sample  of  this  listing  is  shown  in 
Figure  IV- 16. 

(14)  Reply  Past  Due  for  over  $1,000  Review  Items. 

This  listing  acts  as  an  internal  followup  and  is  a  list  of  items 
output  for  review  on  the  SSR  Items  with  Total  Dollar  Value  over 
$1000  for  review  for  which  a  reply  has  not  been  posted  to  the 
SSR  Suspense  File  to  clear  the  15-day  suspense.  A  sample  of  this 
listing  is  shown  in  Figure  IV-17. 

(15)  SSR/Advice  for  Weapons  Integrated  Materiel 
Manager  .  This  is  a  listing  of  valid  incoming  SSR  transactions 
and  offer  reply  transactions  received  this  processing  cycle.  A 
sample  of  this  listing  is  shown  in  Figure  IV-18. 

(16)  SSR  Delinquent  Notice  for  Air  Force  Weapons 
Integrated  Materiel  Manager.  This  list  serves  as  an  internal 
followup  and  contains  incoming  SSR  transactions  for  which  an 
advice  has  not  been  posted  to  the  SSR  Suspense  File  within  25 
days  for  NSN  items  or  60  days  for  Part  Number  items.  A  sample 
of  this  listing  is  shown  in  Figure  IV-19. 

(17)  Unmatch  Print  Code  List.  This  list  contains 
all  records  not  output  on  one  of  the  above  listings. 

G.  DETAILED  MONTHLY  SSR  APPLICATION  DESCRIPTION 


The  Monthly  SSR  Application  performs  monthly  processing 
actions  and  consists  of  three  program  modules  as  shown  in  Figure 
IV-20.  These  program  modules  are  the  Monthly  SSR  Suspense  File 
Maintenance,  Positive  NSN  Table  File  Maintenance  and  SSR  Summary 
Report  Generator. 

Each  of  these  program  modules  are  executed  independently  of 
one  another;  however,  the  Monthly  SSR  Suspense  File  Maintenance 
Program  Module  must  be  completed  before  either  of  the  others  are 
executed.  Each  program  module  is  executed  once  per  month  in  a 
batched  sequential  mode. 

1  .  Monthly  SSR  Suspense  File  Maintenance 


a.  Input s •  The  current  SSR  Suspense  File  on  magnetic 
tape  is  the  single  input  to  this  program  module. 

b.  Files  .  No  files  are  accessed  by  this  program 

module  . 
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Figure  IV-18 


AIM  PONCE  BE  APPLICATION  PHASE  II  (MONTHLY  PROCESS! HOI 


c.  Processing.  This  program  module  uses  the  SSR  Suspense 
File  to  produce  several  functional  outputs  and  performs  a  purge 

on  the  SSR  Suspense  File.  This  program  module  first  pulls  monthly 
SSR  activity  data  from  the  SSR  Suspense  File.  This  data  is  sum¬ 
marized,  edited  and  output  as  a  Summary  Total  List  and  a  Summary 
Totals  Transaction  File.  Next,  the  program  module  analyzes  the 
SSR  Suspense  File  on  an  item  basis.  All  items  having  a  process 
date  over  one  year  old  are  deleted  from  the  file  whether  or  not 
they  are  complete  (accept  advice  received/provided);  items  not 
complete  are  printed  on  the  Deleted  Open  SSR  Items  List.  There 
is  currently  no  provision  for  automated  purge  of  PDSSR  transac¬ 
tions  from  the  SSR  Suspense  File.  Outgoing  SSR  transactions  on 
the  SSR  Suspense  File  for  which  an  accept  advice  was  received 
since  the  last  monthly  cycle,  and  have  an  NSN  present,  have  trans¬ 
actions  formatted  and  output  to  the  Accept  Advice  NSNs  Transac¬ 
tion  File.  An  Updated  SSR  Suspense  File  is  produced  in  addition 
to  a  microfiche  copy  of  the  updated  file,  a  microfiche  cross- 
reference  to  this  file  and  a  listing  of  complete  and  open  items 
on  the  file. 

d.  Outputs  .  There  are  several  outputs  from  this  program 
module  as  shown  in  Figure  IV-20. 

(1)  Summary  Totals  List.  This  is  a  listing  of  Sum¬ 
mary  Totals  which  reflect  monthly  activity  on  the  SSR  Suspense 
File  . 

(2)  SSR/Document  List.  This  is  a  two-part  listing 

of  items  on  the  Updated  SSR  Suspense  File.  One  part  of  this  list¬ 
ing  contains  open  items  in  PCC,  Document  Number,  ISN  and  Activity 
Code  sequence.  The  second  part  contains  completed  items  in  PCC, 
and  Document  Number  sequence.  This  list  is  used  functionally 
for  local  records  management. 

(3)  Microfiche  Cross  Reference  (XREF)  File.  This 
is  a  listing  of  items  on  the  updated  SSR  Suspense  File  cross- 
referencing  NSN  or  Part  Number  to  the  SSR  transaction  control 
elements.  It  is  produced  as  microfiche  rather  than  hard  copy. 

(A)  Microfiche  Suspense  File.  This  is  a  listing  of 
all  items  on  the  Updated  SSR  Suspense  File  produced  on  micro¬ 
fiche. 


(5)  Updated  SSR  Suspense  File.  This  file  is  iden¬ 
tical  to  the  input  SSR  Suspense  File,  less  purged  items.  It  will 
be  used  in  the  next  daily  processing  cycle. 

(6)  Deleted  Open  SSR  Items.  This  is  a  listing  of 
items  purged  from  the  SSR  Suspense  File,  but  had  not  received 
final  advice.  These  items  are  to  be  reviewed  by  the  functional 
user  for  possible  further  action. 
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(7)  Accept  Advice  NSNs.  This  is  a  transaction  file 
containing  outgoing  SSR  items  having  an  NSN  assigned  and  having 
received  accept  advice  since  the  last  monthly  processing  cycle. 
As  noted  in  Figure  IV-20,  this  transaction  file  when  produced  by 
OOALC,  OCALC,  SAALC  and  WRALC  is  transmitted  via  Bulk  Data  Net¬ 
work  (BDN)  to  SMALC  for  further  processing.  The  BDN  is  an 
electronic  transmittal  network  between  the  ALCs  similar  to  the 
AUTODIN  system. 

(8)  Summa r y  Totals.  This  is  a  transaction  file 
containing  summary  data  identical  to  that  printed  on  the  Summary 
Totals  List.  As  shown  in  Figure  IV-20,  these  transactions  are 
also  transmitted  by  each  ALC  to  SMALC  via  BDN  on  a  monthly  basis 
for  further  processing. 

2 .  Positive  NSN  Table  File  Maintenance 

a  •  Inputs.  Inputs  to  this  program  module  include  the 
Accept  Advice  NSNs  Transactions  Files  from  each  of  the  ALCs  and 
the  current  Positive  NSN  Table  File. 


( 1) 

OOALC 

Accept 

Advice 

NSNs 

(2) 

OCALC 

Accept 

Ad  v  ice 

NSNs 

(3) 

SMALC 

Accept 

Advice 

NSNs 

(4) 

SAALC 

Accept 

Advice 

NSNs 

(5) 

WRALC 

Accept 

Advice 

NSNs 

(6) 

Positive  NSN 

Table 

File 

b.  Files .  No  files  are  accessed  by  this  program  module. 

c .  P  rocessing 

This  program  module  file  maintains  the  Positive  NSN 
Table  File.  Accept  Advice  NSNs  are  received  from  the  five  ALCs 
for  processing  at  SMALC.  This  processing  results  in  the  updating 
of  the  Positive  NSN  Table  File  so  that  it  includes  items  accepted 
for  support  by  other  Services,  DLA  and  GSA  regardless  of  the  Air 
Force  SICC.  The  updated  file  is  then  transmitted  by  SMALC  to  the 
other  ALCs  via  BDN  for  use  in  the  Daily  SSR  Application  processing 
cycle.  This  way,  all  the  ALCs  are  using  the  same  Positive  NSN 
Table  File  in  the  dally  processing  cycle. 

The  ALC  Accept  Advice  NSNs  Transaction  Files  are  first 
sorted  and  merged  into  NSN  sequence.  Each  NSN  is  then  checked 
against  the  Positive  NSN  Table  File.  When  the  NSN  is  not  on  this 
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file,  it  is  added.  When  the  NSN  is  already  on  the  file,  the  moat 
current  accept  date  is  placed  on  the  file.  When  an  NSN  on  the 
Positive  NSN  Table  File  is  encountered  with  an  accept  date  over 
two  years  old,  the  NSN  is  purged  from  the  file. 

d.  Output .  The  single  output  from  this  file  is  the  Po¬ 
sitive  NSN  Table  File.  This  file  is  transmitted  via  BDN  to  the 
other  ALCs  by  SMALC  for  use  in  the  next  daily  processing  cycle 
of  the  SSR  Application. 

3 .  SSR  Summary  Report  Generator 

a.  Input  s  .  Inputs  to  this  program  module  include  the 
Summary  Totals  Transaction  Files  from  each  of  the  ALCs.  On  a 
monthly  basis  OOALC,  OCALC,  SAALC  and  WRALC  forward  these  trans¬ 
actions  via  BDN  to  SMALC  for  processing. 


(1) 

OOALC 

Summary 

Totals 

(2) 

OCALC 

Summary 

Totals 

(3) 

SMALC 

Summary 

Totals 

(4) 

SAALC 

Summary 

Totals 

(5) 

WRALC 

Summary 

Totals 

b.  Files 

No 

files  are  accessed  by 

this  program  module. 

c .  Processing  . 

This 

program  module 

is  executed  at 

SMALC  only.  The  Summary  Totals  data  from  each  ALC  is  sorted, 
combined  and  edited  into  a  single  output  report. 

d.  Output .  The  single  output  from  this  program  module 
is  the  Monthly  SSR/Advice  Totals  Report.  This  report  is  pro¬ 
duced  on  microfiche  and  represents  SSR  activity  during  the 
monthly  processing  cycle  on  a  Air  Force  wide  basis.  Samples  of 
this  report  are  shown  in  Figures  IV-21  and  IV-22. 
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Figure  IV-21 


Figure  IV-22 


CHAPTER  V 


MARINE  CORPS 


A.  INTRODUCTION 


The  Marine  Corps  Unified  Material  Management  System  (MUMMS) 

Is  a  standard  ADP  system  used  within  the  Marine  Corps  at  the 
Marine  Corps  Logistics  Support  Base  Atlantic  (MCLSBA).  MCLSBA 
also  acts  as  the  system  design  activity  for  MUMMS,  responsible 
for  the  design,  programming  and  maintenance  of  MUMMS  subsystems, 
applications  and  program  modules.  SSR  processing  within  the 
Marine  Corps  is  being  developed  within  MUMMS  in  the  Technical 
Data  Management  Subsystem.  Presently  the  automation  of  SSR  pro¬ 
cessing  within  the  Marine  Corps  is  under  development.  Therefore, 
in  this  section,  the  System  Design  Process  and  System  Documenta¬ 
tion  will  be  discussed  generally,  followed  by  an  overview  of  the 
conceptual  approach  being  used  by  the  Marine  Corps  in  automating 
SSR  processing. 

B.  SYSTEMS  DESIGN  PROCESS 


The  development  of  all  automated  systems  falls  under  the 
purview  of  the  Commandant  of  the  Marine  Corps  at  Headquarters, 
United  States  Marine  Corps  (HQ  USMC).  Generally,  while  policy, 
management  control  and  funding  are  the  re s p ons i b i 1 i c y  of  Head¬ 
quarters  USMC;  operational,  technical  and  design  control  are 
responsibilities  of  MCLSBA.  As  a  result,  the  systems  design 
of  MUMMS  is  performed  at  MCLSBA  with  Headquarters,  USMC  appro¬ 
val  required  during  certain  phases  of  the  design  process.  Fig¬ 
ure  V  —  1  illustrates  the  organizations  involved  in  MUMMS  systems 
design.  As  this  figure  shows,  the  design  process  in  the  Marine 
Corps  is  a  joint  effort  between  functional  and  technical  person¬ 
nel.  In  the  case  of  SSR  processing,  the  Technical  Data  Division 
provides  functional  expertise,  the  Logistics  Systems  Support 
Division  provides  systems  design  expertise  and  the  Technical 
Data  Systems  Section  within  the  De s i gn / P r og ra mm ing  Branch,  of 
the  Marine  Corps  Automated  Services  Center,  provides  technical 
support. 

The  Systems  design  process  consists  of  three  distinct  phases: 
Concept,  analysis  and  design,  and  implementation  and  operations. 
Each  phase  is  made  up  of  several  steps,  with  each  step  considered 
a  milestone  in  the  total  design.  Each  of  the  phases  and  the 
related  steps  are  discussed  below. 
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1.  The  Concept  Phase  consists  of  four  steps:  Concept  For¬ 
mulation  Concept  Approval,  Development  of  the  Automated  Data 
System  (ADS)  Development  Plan,  and  Approval  of  the  ADS  Develop¬ 
ment  Plan. 

a.  During  concept  formulation,  the  functional  user  con¬ 
ducts  an  informal  analysis  of  the  problem  identified. 

b.  Concept  approval  commits  resources  to  study  the  con¬ 
ceptual  approach  to  validate  the  existence  of  a  problem  and  that 
a  solution  lies  within  the  conceptual  approach. 

c.  The  ADS  Development  Plan  is  developed  by  clarifying 
the  technical,  operational  and  economic  feasibility  of  the  system 
development  and  identifying  how  the  system  will  provide  for  solu¬ 
tion  of  the  problem  identified  in  the  conceptual  approach. 

d.  Approval  of  the  ADS  Development  Plan  provides  author¬ 
ization  to  the  functional  manager  to  commit  resources  to  perform 
the  systems  analysis  and  design. 

2.  The  Analysis  and  Design  Phase  consists  of  four  steps: 
analysis  and  design,  design  approval,  prog ram/ t e s t / debug ,  and 
test  ac ce p t ance / i mp le men t a t i on  request. 

a.  The  analysis  and  design  is  performed  by  technical 
personnel  and  develops  an  automated  system  designed  to  meet  the 
objectives  of  the  conceptual  approach. 

b.  The  automated  system  design  must  be  approved  by  the 
Commandant  of  the  Marine  Corps  prior  to  system  development. 

c.  The  designed  system  is  then  programmed  and  tested 
using  technical  and  user  documentation  including  live  data  from 
the  operational  environment. 

d.  The  Functional  Manager  approves  the  designed  system 
for  implementation  when  test  results  are  accepted.  At  this 
point  an  implementation  request  is  prepared  and  forwarded  to  the 
Commandant  of  the  Marine  Corps  for  approval. 

3.  The  Implementation  and  Operations  Phase  consists  of 

three  steps:  implementation,  field  guidance  and  systems  review. 

a.  The  system  is  implemented  upon  approval  by  the  Com¬ 
mandant  of  the  Marine  Corps. 

b.  The  functional  manager  provides  technical  and  user 
guidance  for  system  implementation. 
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c.  After  implementation  the  functional  manager  performs 
an  operational  systems  review  to  determine  if  processing  objec¬ 
tives  from  the  conceptual  approach  are  met. 

C.  SYSTEM  DOCUMENTATION 


The  initiating  document  in  the  Marine  Corps  is  a  Concept 
Statement  developed  by  the  functional  manager.  Upon  approval  of 
the  concept,  an  ADS  Plan  is  developed  consisting  of  a  Feasibility 
Study,  Functional  Description,  Data  Requirements,  Economic  Anal¬ 
ysis,  and  ADP  Equipment  Specifications.  When  the  ADS  Plan  is 
approved,  the  System  Specification,  Program  Specification,  Data 
Base  Specification  and  Implementation  Plan  are  developed  for 
approval.  During  the  programming  effort,  an  Operations  Manual 
and  Maintenance  Manual  are  developed  by  technical  personnel  and 
a  Command  and  Management  (User's)  Manual  is  developed  by  the 
functional  manager.  These  manuals  are  distributed  upon  system 
implementation. 

D.  SYSTEM  OVERVIEW 


MUMMS  was  established  as  an  integrated,  centralized,  supply 
management  system  to  satisfy  Marine  Corps  requirements.  MUMMS 
currently  contains  subsystems  in  the  areas  of  Data  Control, 
Inventory  Control,  Stores  Accounting,  Automated  Procurement, 
Mechanization  of  Warehousing  and  Shipment  Processing,  Direct 
Support  Stock  Control,  Technical  Data  Management,  Applications, 
Provisioning,  War  Reserve,  Controlled  Item  Management,  Stratifi¬ 
cation,  Special  Programs,  Supply  Management  Information,  and 
Allotment  Accounting.  The  conceptual  approach  to  automating  SSR 
processing  includes  Integration  of  SSR  generation  in  the  Tech¬ 
nical  Data  Management  Subsystem.  An  overview  of  this  subsystem 
and  other  SSR  related  Interfacing  subsystems  is  shown  in  Figure 
V-2.  Each  of  the  subsystems  shown  in  Figure  V-2  is  discussed 
below. 

1 .  MUMMS  Provisioning  Subsystem 

a.  Inputs  .  There  are  two  inputs  to  this  subsystem. 
These  are  PTD  as  card  or  magnetic  tape  and  NSN  Notifications 
from  the  Technical  Data  Management  Subsystem. 

(  1 )  Provisioning  Technical  Documentation  (PTD). 

This  PTD  is  submitted  by  the  contractor  as  hard  copy  and  is 
translated  to  card  or  magnetic  tape  format  for  input  to  this 
subsystem. 


(2)  NSN  Notifications.  These  transactions  contain 
NSNs  matched  through  the  DLSC  screening  process  in  the  Technical 
Data  Management  Subsystem. 
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b.  Files  .  There  are  two  major  files  used  by  this  sub¬ 
system  in  generating  SSR  candidates.  These  are  the  End  Item 
Data  File  and  the  Maintenance  Data  File. 

(1)  MUMMS  End  Item  Data  File.  This  file  contains 
data  related  to  the  end  item  being  provisioned.  This  is  an 
indexed  sequential  disk  file  and  is  the  source  of  PDSSR  trans¬ 
action  data. 


(2)  MUMMS  Maintenance  Data  File.  This  indexed 
sequential  disk  file  contains  data  relating  to  each  maintenance 
significant  item  within  the  end  item  being  provisioned. 

c.  Processing.  Processing  within  this  subsystem  gen¬ 
erally  consists  of  receiving  the  PTD,  validating  it  and  loading 
it  to  the  appropriate  files.  The  PTD  submitted  to  this  subsystem 
consisting  of  original  contractor  data  or  updates  to  previously 
submitted  items  is  formatted  and  processed  at  MCLSBA.  After  all 
data  for  an  item  has  been  loaded  to  the  provisioning  files,  this 
subsystem  will  compute  retail  and  replenishment  quantities.  At 
this  point,  items  for  which  an  NSN  is  not  present  are  listed  for 
functional  notification  and  are  passed  to  the  Technical  Data 
Management  Subsystem  for  DLSC  screening.  This  group  of  items 
contains  both  SSR  candidates  and  items  which  will  be  retained 

for  management  by  the  Marine  Corps.  NSN  Notifications  received 
from  the  Technical  Data  Management  Subsystem  are  used  to  update 
the  Maintenance  Data  File  record  with  the  NSN.  The  Provisioning 
Subsystem  also  feeds  data  to  the  Inventory  Control  Subsystem. 

d.  Outputs.  There  are  several  outputs  from  this  sub¬ 
system. 


(1)  NSN  Required  List.  This  is  a  list  of  items  to 
be  managed  by  the  Marine  Corps  which  require  NSN  assignment  and 
SSR  Candidates  . 

(2)  SSR  Candidate  Transactions.  These  transactions 
are  part  numbers  requiring  DLSC  screening  action.  These  trans¬ 
actions  contain  enough  data  to  generate  PDSSR  and  LISSR  transac¬ 
tions  . 


(3)  Requirements  Data  Transactions.  These  transac¬ 
tions  contain  computed  requirements  to  be  lodged  in  Inventory 
Control  Subsystem  Files. 

2 .  MUMMS  Technical  Data  Management  Subsystem 

a.  Inputs  .  There  are  three  inputs  to  this  subsystem 
related  to  SSR  processing.  These  are  SSR  Candidate  Transactions, 
SSR  Transactions,  and  DLSC  Replies. 
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(1)  SSR  Candidate  Transactions.  These  transactions 
were  passed  to  this  subsystem  by  the  provisioning  subsystem  for 
DLSC  screening  action. 

(2)  SSR  Advice  Transactions.  These  are  manually 
generated  outgoing  SSR  transactions  and  incoming  advice  transac¬ 
tions  from  IMMs. 

(3)  DLSC  Replies.  These  are  replies  to  DLSC  in¬ 
quiries  generated  in  a  previous  processing  cycle. 

b.  Files.  There  are  three  files  used  by  this  subsystem: 
System  Support  Record  File,  Item  Intelligence  File  and  Suspense 
File. 


(1)  MUMMS  System  Support  Record  File.  This  disk 
file  is  used  to  provide  control  information  in  DLSC  screening 
transact  ions  . 

(2)  MUMMS  Item  Intelligence  File.  This  disk  file 
contains  identification,  acquisition  and  management  data  relating 
to  items  used  by  and  managed  by  the  Marine  Corps. 

(3)  Suspense  File.  Thio  disk  file  contains  a  record 
of  all  items  submitted  to  DLSC  for  screening  and  under  the  con¬ 
ceptual  approach  will  contain  outgoing  SSR  transactions  submitted 
to  IMMs  for  action. 

c .  Process ing 

SSR  Candidate  Transactions  are  formatted  into  DLSC 
screening  transactions  using  control  data  from  the  System  Support 
Record  File  and  output  to  the  DLSC  Inquiries  File.  These  trans¬ 
actions  are  also  retained  in  the  Suspense  File  awaiting  a  DLSC 
Reply.  When  a  DLSC  reply  Is  received,  the  transactions  are  pulled 
from  the  Suspense  File  and  the  reply  is  analyzed.  When  an  exact 
match  is  returned  by  DLSC,  a  PDSSR  transaction  and  associated 
LISSR  transaction  are  automatically  generated  and  punched  on  stan¬ 
dard  EAM  cards.  A  record  of  the  SSR  transactions  Is  maintained 
on  the  Suspense  File.  For  other  types  of  DLSC  Replies  (Multiple 
Matches/No  Match)  a  list  is  produced  for  manual  action.  SSR 
transactions  for  these  items  must  be  manually  generated  and  Input 
to  this  subsystem  to  establish  a  record  of  the  submittal  on  the 
Suspense  File.  When  advice  transactions  are  received,  they  must 
be  input  to  this  subsystem  to  clear  the  item  from  the  Suspense 
File. 


Exact  matches  returned  from  DLSC  result  in  several 
other  actions  being  taken  automatically.  First,  the  NSN  is  fed 
to  the  Provisioning  Subsystem  as  an  NSN  Notification.  Also,  the 
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NSN  Is  screened  against  the  Item  Intelligence  File,  and  if  not 
found,  Is  placed  on  the  Item  Intelligence  File  and  Is  forwarded 
to  the  Inventory  Control  Subsystem. 

This  concludes  the  conceptual  approach  to  automated 
SSR  process  i  r.  g  in  the  Marine  Corps.  Specific  Information  such 
as  that  presented  for  the  other  Services  has  not  yet  been  devel¬ 
oped  in  the  Marine  Corps. 

d .  0  u  t  pu  t  s  .  The  outputs  from  this  subsystem  are  NSN 
Notifications,  SSR/Advlce  Transactions,  SSR  item  listing,  DLSC 
screening  results,  DLSC  Inquiries,  and  New  Item  Data  transac.  - 
t  Ions  . 

(1)  NSN  Notifications.  These  are  transactions  for 
which  an  exact  match  reply  was  received  as  a  result  of  screening 
a  Part  Number  against  DLSC  flies.  The  NSN  matched  is  returned 
to  the  Provisioning  Subsystem  to  update  the  Maintenance  File. 

(2)  SSR/Advlce  Transactions.  These  EAM  cards  are 
produced  as  a  result  of  automated  SSR  transaction  generation, 
input  of  manually  generated  SSR  transactions  to  the  Suspense 
File  and  Input  of  advice  transactions  received  from  IMMs. 

(3)  SSR  Item  Listing.  This  is  a  list  of  items 
requiring  manual  SSR  transaction  generation. 

(4)  DLSC  Screening  Results.  This  is  a  listing  of 
replies  received  from  DLSC. 

(5)  DLSC  Inquiries  .  These  are  screening  transac¬ 
tions  to  be  forwarded  to  DLSC  for  processing. 

(6)  New  Item  Data  Transactions.  These  are  transac¬ 
tions  generated  for  exact  matches  received  from  DLSC  which  do 
not  reside  on  the  Item  Intelligence  File.  These  transactions 
are  forwarded  to  the  Inventory  Control  Subsystem. 

3 .  MUMMS  Inventory  Control  Subsystem 

a.  Inputs  .  The  inputs  to  this  subsystem  consist  of 
Requirements  Data  transactions  from  the  Provisioning  Subsystem 
and  New  Item  Data  transactions  from  the  Technical  Data  Manage¬ 
ment  Subsystem . 

(1)  Requirements  Data  Transactions.  These  transac¬ 
tions  contain  requirements  data  to  be  added  to  the  Project 
Requirements  File. 
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(2)  New  Item  Data  Transactions.  These  transactions 
contain  items  to  be  added  to  the  Master  Inventory  File. 

b-  Files  .  There  are  two  major  MUMMS  files  associated 
with  this  subsystem.  These  are  the  Project  Requirements  File 
(PRF)  and  the  Master  Inventory  File  (MIF). 

(1)  MUMMS  Project  Requirements  File  (PRF).  This 
disk  file  acts  as  a  control  file  and  contains  project  require¬ 
ments  which  are  loade d / chang ed / re  lea s e d  by  the  project  manager. 

(2)  MUMMS  Master  Inventory  File  (MIF).  This  is  an 
indexed  sequential  disk  file  containing  inventory  management 
data  for  NSNs  managed  and  used  by  the  Marine  Corps. 

c.  Processing .  Requirements  Data  Transactions  from  the 
Provisioning  Subsystem  are  lodged  in  the  PRF.  New  Item  Data 
transactions  are  used  to  establish  new  items  on  the  MIF. 

d.  Outputs  .  Outputs  from  this  subsystem  are  unknown. 


CHAPTER  VI 


DEFENSE  LOGISTICS  AGENCY 


A.  INTRODUCTION 


The  Standard  Automated  Materiel  Management  System  (SAMMS)  is 
a  standard  ADP  system  used  within  the  Defense  Logistics  Agency 
(DLA)  at  the  Defense  Supply  Centers  (DSCs).  The  DLA  Systems 
Automation  Center  (DSAC)  is  the  central  systems  design  activity 
responsible  for  the  design,  programming  and  maintenance  of  indi¬ 
vidual  subsystems,  applications,  and  program  modules  within  SAMMS 
as  well  as  other  standard  ADP  systems  used  by  DLA.  SAMMS  is 
implemented  at  all  DSCs  and  each  DSC  maintains  a  separate  ADP 
staff  responsible  for  the  scheduling  and  execution  of  SAMMS  Sub¬ 
systems.  The  SSR  Subsystem  (designated  as  the  Provisioning  Sub¬ 
system  by  DLA)  was  developed  as  a  separate  Subsystem  of  SAMMS 
and  interfaces  primarily  with  the  Technical  and  Logistics  Ser¬ 
vices  Subsystem.  The  SSR  Subsystem  also  feeds  transactions  to 
the  Catalog  Subsystem  and  Requirements  Subsystem. 

B.  SYSTEMS  DESIGN  PROCESS 


Supply  support  request  processing  within  DLA  was  automated 
prior  to  the  implementation  of  the  new  IMM  Manual.  This  SSR  Sub¬ 
system  required  changes  to  conform  with  policy,  procedures  and 
formats  set  forth  in  the  new  IMM  Manual.  To  accomplish  the 
required  changes,  a  Request  for  Modification  to  SAMMS  was  devel¬ 
oped  in  the  Directorate  for  Supply  Operations.  The  required 
completion  date  for  these  changes  coincided  with  the  IMM  Manual 
implementation  date. 

DSAC,  as  the  central  systems  design  activity  of  Headquarters, 
DLA,  performs  the  functions  of  systems  design,  development,  imple¬ 
mentation  and  maintenance.  DSAC  also  is  responsible  for  preparing 
and  analyzing  functional  systems  requirements  and  developing  sys¬ 
tems  documentation  for  both  automated  systems  and  functional  use. 
The  organizational  structure  of  DSAC  is  shown  in  Figure  VI-1. 

The  primary  functions  of  systems  design,  development,  implementa¬ 
tion  and  maintenance  are  performed  by  the  Directorates  of  Admin¬ 
istrative  Management  Systems,  Contract  Administration  Services, 
Depot  Management  Systems  and  Materiel  Management  Systems.  The 
Office  of  Planning  and  Management  and  the  Office  of  Technical 
Support  provide  management  and  operations  for  DSAC.  The  Direc¬ 
torate  of  Telecommunications  provide  telecommunications  support 
including  the  DLA  Systems  interfaces  with  AUTODIN.  The  SSR  Sub¬ 
system  is  the  responsibility  of  the  Directorate  of  Materiel 
Management  Systems. 
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The  organization  of  the  Directorate  of  Materiel  Management 
Systems  is  shown  in  Figure  VI-1.  This  Directorate  is  respon¬ 
sible  for  SAMMS  which  performs  automated  processing  in  the  func¬ 
tional  areas  of  Distribution,  Requirements,  Finance,  Technical 
and  Logistics  Services,  and  Procurement.  The  Systems  Management 
Office  maintains  system-wide  control  over  SAMMS.  The  Functional 
Requirements  Division  provides  functional  guidance  to  systems 
personnel  and  serves  as  an  interface  between  the  system  developed 
and  the  functional  users.  Each  of  the  other  Divisions  within 
this  Directorate  have  systems  responsibility  in  one  or  more  func¬ 
tional  areas.  It  is  in  these  divisions  where  the  automated  sys¬ 
tems  are  developed  from  functional  requirements.  The  SSR  Sub¬ 
system  was  assigned  to  the  Procurement  and  Provisioning  Division. 

To  accomplish  the  changes  required  by  the  functional  require¬ 
ment  developed  by  Headquarters,  DLA,  the  SSR  Subsystem  was  divided 
into  three  applications.  The  Daily  SSR  Application  performs 
required  actions  on  a  daily  basis.  The  Weekly  SSR  Application 
provides  for  file  maintenance  and  interrogation  capability  into 
an  SSR  History  File  and  the  monthly  application  provides  a  record 
of  monthly  processing  activity  in  the  Subsystem.  The  three  appli¬ 
cations  were  all  completed  and  implemented  concurrently  with  the 
IMM  Manual  on  1  May  1978. 

C .  SYSTEM  DOCUMENTATION 

The  initiating  document  for  the  changes  in  the  SSR  Subsystem 
was  the  Request  for  Modification  to  SAMMS.  This  request  set 
forth  functional  and  general  system  requirements  in  terms  of 
inputs  to  the  system,  files  to  be  generated/used  by  the  system, 
generalized  processing  logic  flow  of  the  system  and  functional 
outputs  required.  The  Procurement  and  Provisioning  Division 
determined  the  application  and  program  module  breakouts.  Systems 
Documentation  is  published  as  a  SAMMS  Documentation  Manual.  This 
documentation  consists  of  generalized  subsystem,  application  and 
program  narratives  In  addition  to  subsystem  flow  charts.  Input 
Record  Formats,  File  Descriptions  and  Output  Formats  are  also 
included.  At  DSAC,  documentation  below  this  level  generally 
consists  of  detailed  program  narratives,  program  logic  flow 
charts,  decision  tables  and  program  listings. 

The  Directorate  for  Supply  Operations  at  Headquarters,  DLA, 
prepared  and  published  supply  operating  procedures  in  Volume  II 
of  the  Supply  Operations  Manual  (Appendix  D,  Reference  30)  for 
use  at  DSCs.  Technical  operations  procedures  (Appendix  D,  Refer¬ 
ence  31)  for  use  at  DSC  were  prepares  and  published  by  DSAC  under 
the  direction  of  the  Technical  and  Logistics  Services  Directorate 
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of  Headquarters,  DLA.  The  content  of  the  material  in  both  of 
these  manuals  is  quite  redundant.  The  procedures  are  nearly 
identical  in  some  parts  and,  in  others  the  material  may  provide 
conflicting  guidance. 

A  training  package  was  developed  by  the  Directorate  for 
Supply  Operations  at  Headquarters,  DLA.  This  training  consisted 
of  a  briefing  given  by  Headquarters,  DLA,  personnel  to  personnel 
at  each  DSC.  The  briefing  generally  covered  the  differences  in 
SSR  processing  between  the  system  in  use  prior  to  1  May  1978  and 
the  new  system. 

D.  SYSTEM  OVERVIEW 


The  SAMMS  was  developed  to  standardize  operations  and  to  meet 
the  operational  needs  of  the  Defense  Supply  Centers  for  executing 
policy  and  procedures  established  by  Headquarters,  DLA.  Currently, 
SAMMS  consists  of  subsystems  supporting  the  functional  areas  of 
materiel  distribution,  materiel  requirements,  materiel  procure¬ 
ment,  functional  accounting,  and  technical  and  logistics  services. 
The  SSR  process  was  designed  as  a  single  subsystem  within  SAMMS 
to  automate  the  processing  of  incoming  SSR  transactions  received 
by  the  DSCs  as  CIMMs.  An  overview  of  this  subsystem  and  the 
major  interfacing  subsystems  is  shown  in  Figure  VI-2.  This 
figure  illustrates  that  incoming  SSR  transactions  and  local  file 
maintenance  transactions  are  manually  input  to  the  SSR  Subsystem, 
while  followup  transactions  and  offer  reply  transactions  are 
input  to  this  Subsystem  either  manually  when  received  by  mail  or 
automatically  when  received  via  AUTODIN.  Formatted  DLSC  replies 
are  passed  from  the  Technical  and  Logistics  Services  Subsystem. 

Each  of  the  subsystems  in  Figure  VI-2  are  discussed  in  general 
fashion  followed  by  detailed  discussions  of  each  of  the  SSR 
Applications  . 

1.  SAMMS  Technical  and  Logistics  Services  Subsystem.  This 
subsystem  consists  of  several  applications  performing  automated 
processing  in  support  of  technical  and  logistics  services  func¬ 
tions.  This  subsystem  performs  initial  processing  on  DLSC  reply 
transactions  . 

a  .  Inputs  .  There  are  two  inputs  to  this  subsystem. 

These  are  DLSC  reply  transactions  and  Rejected  Item  transactions. 


(1)  DLSC  Reply  Transactions.  These  transactions 
are  replies  to  DLSC  Inquires  generated  by  the  SSR  Subsystem,  NSN 
assignments  generated  for  Part  Number  SSR  transactions  by  the 
Catalog  Subsystem,  and  catalog  approvals  for  cataloging  transac¬ 
tions  generated  by  the  Catalog  Subsystem. 
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(2)  Rejected  Item  Transactions.  These  are  transac¬ 
tions  from  the  Catalog  Subsystem  indicating  reject  advice  trans¬ 
actions  should  be  generated  for  these  items. 

b.  Files .  The  only  file  accessed  by  this  subsystem  is 
the  Closed  Loop  Suspense  File.  It  contains  a  record  of  all 
active  transactions  submitted  to  DLSC.  This  disk  file  is  com¬ 
posed  of  variable  length  records  sequenced  on  DLSC  Document 
Number  and  is  accessed  sequentially. 

c.  Proce s sing.  Processing  in  this  subsystem  is  based 
on  the  type  of  SSR  transaction  for  which  the  DLSC  inquiry  was 
generated  and  the  reply  from  DLSC.  Generally,  when  the  DLSC 
reply  indicates  the  inquiry  received  was  unprocessable,  the 
Technical  and  Logistics  Services  Subsystem  will  automatically 
regenerate  the  inquiry  by  extracting  necessary  data  from  the 
Closed  Loop  Suspense  File.  The  SSR  Subsystem  is  notified  of  the 
resubmittal.  When  the  inquiry  is  returned  as  unprocessable  a 
second  time,  it  is  listed  on  the  DLSC  File  Maintenance  Reject 
Listing  for  manual  action.  Transactions  forwarded  to  the  SSR 
Subsystem  are  not  in  a  DLSC  reply  format.  They  are  in  a  simpler 
file  maintenance  format.  When  DLSC  results  are  forwarded  to  the 
SSR  Subsystem,  the  inquiry  transaction  is  purged  from  the  Closed 
Loop  Suspense  File. 

(1)  NSN  Inquiry  Replies.  DLSC  inquiries  generated 
for  NSN  SSR  items  are  a  dual  process  when  the  NSN  is  found  in 
DLSC  files.  When  the  DLSC  reply  indicates  a  match  was  found  in 
DLSC  files  and  the  NSN  has  not  been  cancelled,  the  DLSC  data  and 
SSR  data  is  passed  to  the  IMC  Classification  Application  of  the 
Catalog  Subsystem.  The  IMC  Classification  Application  processes 
these  transactions  and  submits  appropriate  catalog  transactions 
to  DLSC.  When  approvals  for  these  catalog  transactions  are 
received  in  the  Technical  and  Logistics  Services  Subsystem,  the 
SSR  Subsystem  is  notified  for  generation  of  accept  advice  to  the 
SICC.  The  IMC  Classification  Application  may  return  items  to 
the  Technical  and  Logistics  Services  Subsystem  for  return  of 
reject  advice  to  the  SICC.  When  the  IMC  Classification  returns 
a  reject  reply,  the  Technical  and  Logistics  Services  Subsystem 
determines  the  proper  reject  advice  to  be  returned  to  the  SSR 
Subsystem  (e.g.,  IMC  in  DLSC  records  not  "Z,"  item  managed  by 
another  activity,  etc.).  If  the  NSN  in  the  inquiry  transaction 
is  not  found  in  DLSC  files  or  status  in  DLSC  files  indicates  the 
NSN  has  been  cancelled  with  or  without  replacement,  this  infor¬ 
mation  is  passed  to  he  SSR  Subsystem  for  generation  of  reject 
advice  transaction  co  the  SICC. 

(2)  PSCN  Inquiry  Replies.  DLSC  replies  to  PSCN 
inquiries  generally  indicate  the  PSCN  was  found  in  DLSC  files, 
the  PSCN  was  not  found  in  DLSC  files,  or  the  PSCN  was  found  in 
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DLSC  files,  but  has  been  cancelled  with  or  without  replacement. 
The  Technical  and  Logistics  Services  Subsystem  reformats  these 
replies  and  forwards  them  to  the  SSR  Subsystem.  Replies  that 
indicate  the  PSCN  was  found  and  has  not  been  cancelled  are 
listed  on  the  NIIN/PSCN  Interrogation  Search  Replies  list. 

(3)  Part  Number  Inquiry  Replies.  DLSC  replies  to 
part  number  inquiries  generally  indicate  a  match  to  a  single 
NSN,  PSCN,  multiple  NSNs  security  classified  item,  or  no  match 
condition.  The  Technical  and  Logistics  Services  Subsystem  re¬ 
formats  each  reply  for  processing  by  the  SSR  Subsystem.  When  a 
PSCN  or  multiple  NSNs  were  matched  and  the  part  number  SSR  was 
submitted  with  an  NSN  Justification  Code,  the  matched  PSCNs/NSNs 
are  listed  on  the  Replies  to  Part  Numbe r /Cha r ac t e r i s t i c s  Screen¬ 
ing  Requests. 

( 4 )  Additional  Reference  Number  Inquiry  Replies. 
When  the  Part  Number  inquiry  was  generated  from  an  additional 
reference  number  transaction,  the  Technical  and  Logistics  Ser¬ 
vices  Subsystem  lists  the  DLSC  reply  on  the  Replies  to  Part 
Numbe r /Cha rac te r i s t i c s  Screening  Requests.  This  information  is 
not  passed  to  the  SSR  Subsystem  for  processing.  The  DLSC 
replies  must  be  manually  reviewed  and  action  taken  to  add  these 
reference  numbers  to  DLSC  files  when  necessary. 

(5)  NSN  Assignments.  When  an  NSN  assignment  is 
received  from  DLSC,  the  Technical  and  Logistics  Services  Sub¬ 
system  passes  the  transaction  to  the  SSR  Subsystem. 

d.  Outputs .  As  shown  in  Figure  VI-2  there  are  three 
outputs  from  this  Subsystem.  These  are  the  reformatted  DLSC 
Replies,  Functional  Listings,  and  DLSC  Screening  NSN  Matches. 

(1)  Reformatted  DLSC  Replies.  These  are  transac¬ 
tions  from  which  initial  processing  has  been  done  by  the  Tech¬ 
nical  and  Logistics  Services  Subsystem  and  are  passed  to  the  SSR 
Subsystem  for  further  processing. 

(2)  Functional  Listings.  There  are  three  listings 
produced  by  this  subsystem  for  functional  use. 

( a )  DLSC  File  Maintenance  Reject  Listing. 

This  listing  contains  transactions  which  could  not  be  processed 
by  DLSC  due  to  improper  format,  data,  etc. 

( b )  Replies  to  Part  Numbe r / Char ac t er i s t ic s 
Screening  Request.  This  list  contains  part  number  screening 
results  for  additional  reference  numbers  submitted  with  SSR 
transactions  and  part  number  screening  results  for  certain  other 
conditions  described  above. 
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(c )  NIIN/PSCN  Interrogation  Search  Replies. 

This  list  contains  PSCN  screening  results  when  the  PSCN  sub¬ 
mitted  matches  to  DLSC  files. 

(3)  DLSC  Screening  NSN  Matches.  These  are  transac¬ 
tions  containing  DLSC  catalog  management  data  for  processing  in 
the  IMC  Classification  Application. 

2.  SAMMS  SSR  Subsystem.  The  SSR  Subsystem  consists  of  three 
applications;  a  daily  application,  a  weekly  application  and  a 
monthly  application.  Automated  processing  in  this  Subsystem 
includes  generating  DLSC  screening  transactions,  maintaining  an 
SSR  Suspense  File  and  SSR  History  File,  processing  file  mainte¬ 
nance  transactions,  and  producing  functional  listings. 

a.  Inputs  .  There  are  five  inputs  to  this  Subsystem. 
These  are  Incoming  Provisioning,  Non pr o v is ioni ng ,  and  Change  SSR 
Transactions;  Incoming  Followup  Transactions;  Incoming  Offer 
Reply  Transactions;  Reformatted  DLSC  Reply  Transactions;  and 
Local  File  Maintenance  Transactions. 

( 1 )  Incoming  Provisioning,  Nonprovisioning,  and 
Change  SSR  Transactions.  These  are  SSR  transactions  submitted 
to  a  DSC  as  the  IMM. 

(2)  Incoming  Followup  Transactions.  These  are 
transactions  from  SICCs  requesting  status  on  SSR  transactions 
previously  submitted. 

(3)  Incoming  Offer  Reply  Transactions.  These  are 
transactions  from  SICCs  providing  accept  or  reject  advice  to 
offered  items. 

(4)  Reformatted  DLSC  Reply  Transactions.  These  are 
transactions  from  the  Technical  and  Logistics  Services  Subsystem. 


(5)  Local  File  Maintenance  Transactions.  These  are 
locally  generated  transactions  to  update  the  SSR  Suspense  File, 
generate  advice  to  SICCs  and  interrogate  the  SSR  Suspense  and 
SSR  History  Files. 

b.  Files  .  There  are  seven  files  accessed  by  this  Sub¬ 
system.  These  are  the  Provisioning  Table  File,  the  System 
Master  File,  the  Part  Numbe r /NS N/ P SCN  to  Document  Number  Cross 
Reference  File,  the  Document  Number  to  Part  Number /NSN/PSCN 
Cross  Reference  File,  the  Previsioning  Support  File,  the  SSR 
Suspense  File  and  the  SSR  History  File. 
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(1)  Provisioning  Table  File.  This  sequential  disk 
file  contains  a  Provisioning  Control  Code  ( P CC ) / Ac t i v i t y  Code 
From  (ACF)  Table.  This  table  contains  PCC/ACF  combinations  for 
Weapons  Systems  for  which  support  items  are  to  be  stocked,  based 
on  essentiality  when  the  items  fail  to  meet  stockage  criteria  in 
the  stock/nonstock  decision  tables  used  in  automated  AAC  Method/ 
Level  of  Support  decisions. 

(2)  System  Master  File.  This  sequential  disk  file 
contains  data  used  in  validation  of  some  individual  SSR  data 
elements . 


( 3 )  Part  Numbe r / NS N / P SCN  to  Document  Number  Cross 
Reference  File.  This  sequential  disk  file  is  a  cross  reference 
by  Part  Numbe r / NS N / P SC N  to  the  SSR  Suspense  File  and  by  Document 
Number  to  Part  Numbe r / NSN / P SC N  Cross  Reference  File. 

( 4 )  Document  Number  to  Part  Number/NSN/PSCN  Cross 
Reference  File.  This  sequential  disk  file  serves  as  a  cross 
reference  to  match  DLSC  Replies  back  to  the  SSR  Suspense  File. 

(5)  Provisioning  Support  File.  This  sequential 
disk  file  provides  data  to  the  Procurement  Subsystem  when  an  SSR 
results  in  a  buy  and  ties  the  Purchase  Request  to  a  specific 
SSR  . 


(6)  SSR  Suspense  File.  This  magnetic  tape  file 
acts  as  an  active  suspense  file  of  valid  SSR  item  records  being 
processed  in  the  SSR  Subsystem.  This  file  is  termed  the  Provi¬ 
sioning  File  within  DLA.  This  file  is  accessed  in  a  batched 
sequential  mode  and  contains  only  active  items.  Item  records 
are  purged  from  this  file  and  transferred  to  the  SSR  History 
File  when  completed. 

(7)  SSR  History  File  .  This  file  contains  SSR  items 
which  have  been  completed  for  one  year  after  the  last  item  in 

the  PCC  package  is  complete.  This  file  is  termed  the  Provisioning 
Control  History  File  within  DLA. 

c .  Proce  s  sing 


Processing  in  this  Subsystem  is  accomplished  on  a 
daily,  weekly  and  monthly  basis.  Daily  processing  consists  of 
validation  of  SSR  transactions  and  generation  of  DLSC  screening 
transactions  for  SSR  transactions  input  in  the  current  cycle. 
Reject  advice  transactions  are  generated  based  on  validation 
results  and  DLSC  replies.  Accept,  offer  and  reject  advice  trans¬ 
actions  are  generated  based  on  file  maintenance  transactions. 
Interrogations  are  processed  from  the  functional  user.  Follow¬ 
up  transactions  are  matched  to  the  SSR  Suspense  File  and  are 
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either  passed  to  the  weekly  processing  cycle  or  a  Followup 
Response  Transaction  Is  generated.  Transactions  are  passed  to 
the  SAMMS  Catalog  Subsystem  and  SAMMS  Requirements  Subsystem 
when  appropriate,  and  several  functional  listings  are  produced. 

Weekly  processing  adds  transactions  to  the  SSR  His¬ 
tory  File  and  purges  transactions  from  this  file.  Interroga¬ 
tions  are  matched  to  the  SSR  History  File  and  matched  items  are 
printed.  Followup  transactions  not  matched  in  the  daily  process 
are  matched  to  the  History  File  and  followup  response  transac¬ 
tions  are  generated  to  respond  to  these  followup  transactions. 

Monthly  processing  consists  of  compiling  and  printing 
daily  processing  cycle  activity  for  the  preceding  month. 

d.  Outputs .  There  are  several  outputs  from  this  sub¬ 
system.  These  outputs  are  listed  here;  they  will  be  discussed 
in  detail  in  the  Detailed  SSR  Subsystem  descriptions  that 
f  o 1  low . 


(1) 

Updated  SSR  Suspense 

File  . 

(2) 

Updated  SSR  History 

File  . 

(3) 

DLSC  Inquiries  . 

(4) 

Advice  Transactions. 

(5) 

Closed  Loop  Suspense 

File  . 

(6) 

Functional  Listings. 

(7) 

Skeleton  File  Maintenance  Cards 

(8) 

Catalog  Transactions 

• 

(9) 

Requirements  Transactions. 

3.  SAMMS  Requirements  Subsystem.  As  shown  in  Figure  VI-2 
there  are  two  SSR  related  inputs  to  this  subsystem.  The  require¬ 
ments  transactions  from  the  Catalog  Subsystem  establish  new 
items  in  Inventory  Management  Files.  After  these  new  items  are 
lodged  in  these  files,  the  requirements  transactions  from  the 
SSR  Subsystem  containing  SSR  quantities  are  lodged  in  Inventory 
Management  Files  and  functional  outputs  are  produced  for  inven¬ 
tory  management  to  forecast  requirements  and  initiate  purchase 
requests . 

4.  SAMMS  Catalog  Subsystem.  The  Catalog  Subsystem  receives 
transactions  from  the  Technical  and  Logistics  Services  Subsystem, 


the  SSR  Subsystem  and  manually  generated  transactions.  Trans¬ 
actions  from  the  Technical  and  Logistics  Services  Subsystem  pass 
NSN  screening  matches  to  the  IMC  Classification  Application  of 
the  Catalog  Subsystem.  This  application  compares  DLSC  catalog 
management  data  to  SSR  data  and  generates  Add  User  Transactions, 
upgrades  the  AAC  or  generates  reactivation  actions  as  necessary. 
The  NUN  Assignment  Application  receives  manually  generated  trans¬ 
actions  and  combines  them  with  transactions  from  the  SSR  Subsys¬ 
tem.  These  transactions  are  submitted  to  DLSC  for  further  pro¬ 
cessing  . 

E.  DETAILED  DAILY  SSR  APPLICATION  DESCRIPTION 


The  SAMMS  SSR  Subsystem  consists  of  three  applications.  This 
section  describes  the  Daily  SSR  Application.  The  Daily  SSR  Appli¬ 
cation  consists  of  the  four  program  modules  shown  in  Figure  VI-3. 
Figure  VI-3  is  the  daily  portion  of  the  SSR  Subsystem  shown  in 
Figure  VI-2.  Each  of  the  program  modules  in  Figure  VI-3  is  dis¬ 
cussed  in  terms  of  its  inputs,  files,  processing  and  outputs  in 
the  order  shown  in  the  figure  -  SSR  Append  Sort  Key,  SSR  Valida¬ 
tion,  SSR  Daily  File  Maintenance  and  SSR  Output  Generator.  Each 
of  these  program  modules  processes  transactions  in  a  batch  mode 
and  is  scheduled  in  a  single  job  stream  on  a  daily  basis. 

1 .  SSR  Append  Sort  Key 

a.  Inputs .  There  are  five  inputs  to  this  program 
module  as  shown  in  Figure  VI-3.  These  inputs  are  incoming  SSR 
transactions,  incoming  followup  transactions,  incoming  offer 
reply  transactions,  local  file  maintenance  transactions  and  DLSC 
reply  transactions. 

(1)  Incoming  SSR  Transactions.  These  are  incoming 
provisioning,  nonprovisioning  and  change  SSR  transactions  sub¬ 
mitted  to  a  DSC  as  the  CIMM. 

(2)  Incoming  Followup  Transactions.  These  are 
transactions  from  a  SICC  to  the  DSC  CIMM  requesting  status  on 
SSR  transactions  previously  submitted. 

(3)  Incomlr,  .  fer  Reply  Transactions.  These  are 

replies  to  alternate  .  -titute  items  offered  by  the  DSC  to 

the  SICC  in  lieu  of  .  or  'nwl  item  submitted. 

(4)  Local  File  Maintenance  Transactions.  These  are 
transactions  completed  by  the  functional  user  within  the  DSC  to 
update  the  Provisioning  Table  File,  update  the  SSR  Suspense 
File,  generate  advice  to  the  SICC,  and  Interrogate  the  SSR 
Suspense  File  and/or  SSR  History  File. 
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Figure  VI- 


( 5 )  Reformatted  DLSC  Reply  Transactions  .  These  are 
transactions  forwarded  to  the  Daily  SSR  Application  from  the 
Technical  and  Logistics  Services  Subsystem. 

b.  Files  .  The  single  file  accessed  by  this  program 
module  is  the  Provisioning  Table  File.  This  sequential  disk 
file  contains  the  Provisioning  Control  Code  ( P CC ) / Ac t i v i t y  Code 
From  (ACF)  Table  and  the  Stock/Nonstock  Decision  Tables  used  in 
AAC  assignment.  The  PCC/ACF  Table  from  this  file  is  used  by 
this  program  module. 

c.  Processing 


This  program  module  expands  each  input  transaction 
from  80  characters  to  120  characters  and  establishes  a  sort  key 
in  each  record.  It  also  performs  file  maintenence  on  the  Pro¬ 
visioning  Table  File  and  computes  the  total  dollar  value  of 
LISSR  transactions. 

The  sort  key  established  is  appended  to  the  front  of 
each  input  transaction.  Generally  the  sort  key  for  SSR  transac¬ 
tions  consists  of  a  DLA  peculiar  Use  Code,  ACF,  PCC,  DOR  and 
ISN.  The  sort  key  for  DLSC  reply  transactions  uses  the  DLSC 
Document  Number  in  place  of  the  SSR  Control  Elements. 

PCC  Table  file  maintenance  transactions  are  used  by 
this  program  module  to  add  or  delete  records  from  this  Table. 

The  entire  PCC  Table  is  then  output  to  the  Output  Products  File 
for  printing  on  the  Provisioning  Contol  Code/Weapons  System 
Listing.  Each  input  PDSSR  transaction  is  matched  to  the  PCC 
Table  on  PCC  and  ACF.  The  PCC  Table  contains  PCCs  and  Activity 
Codes  for  Service  Weapons  Systems  approved  for  support  in  the 
DLA  Weapons  Systems  Support  Program.  When  a  PDSSR  transaction 
matches  this  table,  a  '1'  is  placed  in  cc  6  of  the  PDSSR  trans¬ 
action.  This  allows  all  items  matching  this  PDSSR  transaction 
to  be  assigned  an  AAC  indicating  stockage  of  the  item. 

All  LISSR  transactions  containing  a  unit  price  have 
the  total  dollar  value  computed  (replenishment  quantity  times 
unit  price).  Items  which  have  a  total  dollar  value  over  $2,500 
have  the  total  dollar  value  output  with  the  LISSR  transection  to 
the  Output  Products  File  for  printing  on  the  Provisioning  PCC/ 
High  Dollar  Review  List.  All  input  SSR  transactions  are  output 
to  the  Output  Products  File  for  printing  on  the  Provisioning 
PCC/High  Dollar  Review  List.  Also  all  input  transactions  except 
Provisioning  Table  File  file  maintenance  transactions  are  output 
to  the  Sort  File. 
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d.  Ou  t  pu  t  s .  There  are  two  outputs  from  this  program 
module,  the  Sort  File  and  the  Output  Products  File. 

(1)  Sort  File.  This  file  contains  all  transac¬ 
tions,  except  Provisioning  Table  File  file  maintenance  transac¬ 
tions  input  to  the  program  module  in  the  expanded  format  with 
sort  key  added. 

(2)  Output  Products  File.  This  file  contains 
records  to  produce  functional  outputs  in  the  SSR  Output  Generator 
Program  Module  . 

2.  SSR  Validation 


a.  Inputs  .  The  single  input  to  thi  program  module  is 
the  Sort  File  from  the  previous  program  module. 

b.  Files  .  This  program  module  accesses  two  files,  the 
System  Master  File  and  the  Provisioning  Table  File. 

(1)  System  Master  File.  This  sequential  disk  file 
contains  data  for  use  by  all  SAMMS  Subsystems.  This  program 
module  uses  the  the  Activity  Code  Table,  the  Unit  of  Issue  Table, 
etc.,  located  on  this  file  in  the  validation  process. 

(2)  Provisioning  Table  File.  This  program  module 
uses  the  s t oc k / no n s t oc k  decision  tables  for  AAC  determination. 

c .  Processing 


Transactions  from  the  Sort  File  entering  this  pro¬ 
gram  module  are  sequenced  based  on  the  Sort  Key  established  by 
the  previous  program  module.  This  program  module  performs  vali¬ 
dation  on  Incoming  provisioning,  nonprovisioning  and  change  SSR 
transactions  and  some  file  maintenance  transactions. 

SSR  transactions  are  first  validated  for  correct 
control  elements  and  package  combinations.  When  control  ele¬ 
ments  or  package  errors  exist,  these  transactions  are  output  to 
the  output  products  file  for  printing  on  the  Provisioning  Input 
Exceptions  List.  No  further  processing  is  performed  on  these 
transactions.  SSR  transactions  passing  this  validation  that  are 
changes  to  previously  submitted  SSR  transactions  are  output  to 
the  output  products  file  for  printing  on  the  Provisioning  Design 
Change  List.  Only  superseding  change  LISSR  transactions  and 
associated  PDSSR  transactions  continue  processing;  other  changes 
are  dropped  from  further  automated  processing.  Provisioning, 
n on p r o v i s I  on i n g ,  and  superseding  change  LISSR  transactions  which 
pass  control  data  element  and  package  validations  are  validated 
for  correct  detail  data  elements.  These  transactions  are  output 
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to  the  output  products  file  for  printing  on  the  Provisioning  SSR 
List.  When  a  validation  error  is  found,  the  Action  Taken  Code 
(ATC)  to  be  returned  to  the  SICC  is  automatically  assigned  and 
will  appear  beside  the  transaction  in  error  on  the  Provisioning 
SSR  List.  When  an  SSR  transaction  is  found  to  contain  an  inac¬ 
tive  NSN  and  a  nondefinitive  unit  of  issue  during  validation, 
the  transaction  is  output  to  the  output  products  file  for  print¬ 
ing  on  the  SSRs  with  Nondefinitive  Units  of  Issue  listing.  These 
transactions  are  not  rejected,  but  continue  normal  processing. 

Each  LISSR  package  is  then  formatted  into  a  single 
360- charac ter  transaction  containing  PDSSR,  LISSR,  item  name  and 
additional  user  data.  Additional  Reference  Number  transaction 
data  does  not  become  a  part  of  this  expanded  transaction;  how¬ 
ever,  a  DLSC  screening  inquiry  is  generated  for  each  additional 
reference  number  submitted.  The  screening  transactions  are  out¬ 
put  to  the  DLSC  Inquiries  File  and  the  Closed  Loop  Suspense 
File.  The  expanded  transactions,  containing  SSR  transactions 
with  validation  errors,  are  output  to  the  New  SSR  Transactions 
File.  Valid  transactions  have  the  method  and  level  of  support 
determined  before  being  output  to  this  file.  The  method  and 
level  of  support  is  determined  by  passing  items  through  the  AAC 
Filter  shown  in  Figure  VI-A.  The  AAC  determined  is  entered  in 
the  expanded  transaction  before  it  is  output  to  the  New  SSR 
Transaction  File. 


ACQUISITION  ADVICE  CODE  (AAC)  FILTER 


Criteria 

Ye  s -Ac  t i on 

No-Ac  t ion 

Is  recommended  AAC 

Assign  AAC  J 

Continue  pro¬ 

in  SSR  equal  '  J  '  ? 

(centrally  procure, 
nons  tocked  )  . 

cessing  . 

Is  Source  Code 

Assign  AAC  Z 

Cont inue  pro¬ 

In  SSR  equal  ' PB  '  ? 

(stock  as  Insurance 
item)  . 

cessing  . 

Is  Replenishment 

Assign  AAC  D 

Continue  pro¬ 

Quantity  equal  to  or 
greater  than  '12'? 

(centrally  procure, 
stock)  . 

cessing  . 

Is  cc  6  of  PDSSR 

Assign  AAC  Z 

Continue  pro¬ 

equal  to  *  I  *  ? 

(stock  as  NSO  Item). 

cessing  . 

Is  Replenishment  Quan¬ 
tity  equal  to  or  greater 
than  annual  demand  fre¬ 
quency  from  stocked/non- 
stocked  table  in  Provi¬ 
sioning  Table  File? 

Assign  AAC  Z 
(stock  as  NSO  Item). 

Assign  AAC  J . 

Figure  VI-4 
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File  Maintenance  transactions  containing  data  to  be 
returned  to  a  SICC  (e.g.,  ATC,  NSN,  etc.)  are  validated.  When 
an  invalid  condition  exists,  the  file  maintenance  transaction  is 
coded  as  invalid.  All  file  maintenance  transactions,  followup 
transactions,  offer  reply  transactions  and  DLSC  reply  transac¬ 
tions  from  the  sort  file  are  output  to  the  File  Maintenance  Trans 
action  File.  Followup  transactions,  offer  reply  transactions 
and  DLSC  reply  transactions  are  not  validated  in  this  program 
modu  le  . 


d .  Ou  t  pu  t  s  .  There  are  five  output  files  from  this  pro¬ 
gram  module;  the  New  SSR  Transaction  File,  the  File  Maintenance 
Transaction  File,  the  DLSC  Inquiries  File,  the  Closed  Loop 
Suspense  File  and  the  Output  Products  File. 

(1)  New  SSR  Transaction  File.  This  file  contains 
expanded  SSR  transactions  for  processing  in  the  next  program 
module  . 

(2)  File  Maintenance  Transaction  File.  This  file 
contains  transactions  to  be  processed  against  the  SSR  Suspense 
File  in  the  next  program  module. 

( 3 )  DLSC  Inquiries  File  .  This  file  contains  DLSC 
screening  transactions  generated  from  Additional  Reference 
Number  Transactions. 

(4)  Closed  Loop  Suspense  File.  This  file  contains 
a  duplicate  of  the  DLSC  screening  transaction  for  use  by  the 
Technical  and  Logistics  Services  Subsystem. 

(5)  Output  Products  File.  This  file  is  updated  by 
this  program  module.  It  contains  records  to  produce  the  func¬ 
tional  listings  in  the  SSR  Output  Generator  Program  Module. 

3 .  SSR  Daily  File  Maintenance 

a.  Inputs  .  There  ate  two  inputs  to  this  program  module; 
the  New  SSR  Transaction  File  and  the  File  Maintenance  Transaction 
File. 

b.  Files.  This  program  module  uses  four  files  in  pro¬ 
cessing  input  transactions.  These  are  the  Part  Number/NSN/PSCN 
to  Document  Number  Cross  Reference  File,  the  Document  Number  to 
Part  Number/NSN/PSCN  Cross  Reference  File,  the  Provisioning 
Support  File,  and  the  SSR  Suspense  File. 

( 1 )  Part  Number/NSN/PSCN  to  Document  Number  Cross 
Reference  File.  This  sequential  disk  file  is  a  cross  reference 
by  Part  Number/NSN/PSCN  to  the  SSR  Suspense  File  and  the  Docu¬ 
ment  Number  Cross  Reference  File. 


( 2 )  Document  Number  to  Part  Numbe r / NSN/ P SCN  Cross 
Reference  File .  This  sequential  disk  file  serves  as  a  cross 
reference  from  DLSC  Document  Number  to  Part  Number /NSN/PSCN . 

(3)  Provisioning  Support  File.  This  sequential 
disk  file  provides  data  to  the  Procurement  Subsystem  when  an  SSR 
results  in  a  buy  and  ties  the  Purchase  Request  to  a  specific 

SSR  . 


(4)  SSR  Suspense  File.  This  sequential  magnetic 
tape  file  serves  as  an  active  suspense  file  of  SSR  transac tions  . 
This  file  is  made  up  of  360-character  records  in  ACF,  PCC,  DOR 
and  ISN  sequence.  Each  record  on  the  file  is  a  combination  of 
PDSSR  data,  LISSR  data,  Item  Name  Transaction  data,  Additional 
User  Transaction  data.  Ad vice  Transaction  data  and  status  indi¬ 
cators  for  internal  use.  The  data  elements  contained  in  each 
record  are  listed  in  Figure  Vl-5.  As  this  figure  shows,  this 
format  is  significantly  different  from  those  given  in  the  I  MM 
Manual.  Records  are  purged  from  this  file  and  transferred  to 
the  SSR  History  File  by  the  Weekly  SSR  Application  when  final 
advice  has  been  provided  to  the  SICC. 

c.  Processing.  This  program  module  processes  input 
transactions  from  the  New  SSR  Transaction  file  and  the  File 
Maintenance  Transaction  file.  Each  type  of  transaction  (SSR 
transaction,  DLSC  reply,  etc.,)  is  processed  significantly  dif¬ 
ferent  and  will  be  discussed  independently  of  other  transaction 
types  . 


(  1 )  SSR  Transactions 


SSR  transactions  entering  this  program  module 
consist  of  both  valid  and  invalid  transactions.  Invalid  trans¬ 
actions  are  those  which  were  found  to  contain  validation  errors 
by  the  previous  program  module.  Reject  advice  transactions  for 
these  invalid  SSR  transactions  are  automatically  generated  and 
forwarded  to  the  appropriate  SICC  via  AUTODIN.  These  invalid 
transactions  are  output  to  the  History  Transactions  File  and 
records  are  generated  and  output  to  the  Output  Products  File  to 
be  printed  on  the  Provisioning  Sensor  Report  and  the  Provision¬ 
ing  Advice  List. 


Valid  SSR  transactions  are  posted  to  the  SSR 
Suspense  File.  Each  of  these  SSR  transactions  automatically 
have  DLSC  screening  transactions  generated  and  output  to  the 
DLSC  Inquiries  File.  Appropriate  records  are  also  generated  and 
output  to  the  Part  Numbe r / NS N / P SC N  to  Document  Number  Cross 
Reference  File  and  the  Document  Number  to  Part  Numbe r / NSN / P SCN 
Cross  Reference  File.  There  is  one  exception  to  the  above  pro¬ 
cessing  for  valid  SSR  transactions.  When  an  SSR  transaction  is 
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SSR  SUSPENSE  FILE  DATA  ELEMENTS 


Sort  Key  (ACF,  PCC,  DOR,  ISN) 
DLSC  Document  Number 
L I S  S  R  DIC 
End  Item  NSN/Name 
Date  NSN  Required  (if  blank, 
current  date  and  60) 

Date  Repair  Parts  Required 
Contract  Control  Number 
End  Item  Delivery  Code 
FSCM  (Prime) 

Weapon  System  Code 
Number  of  SSRs  Submitted 
Percent  End  Items  East 
Weapons  System  Bypass  Indicator 
TCC 

Original  NSN/PSCN 
Replacement  NSN/PSCN 
Retail  Quantity 
IMC 
AAC 

Replenishment  Quantity 
Quantity  per  End  Item 
Source  Code 
Unit  of  Issue 
Demilitarization  Code 
Procurement  Method  Code 
Interchangeability  Code 
Shelf  Life  Code 
Production  Lea'  Time 
Unit  Price 
Original  FSCM 

Original  Manufacturers  Part 
Number 


Replacement  FSCM 
Replacement  Manufacturers  Part 
Number 

Reference  Number  Format  Code 
Reference  Number  Category  Code 
Reference  Number  Variation  Code 
Document  Availability  Code 
Date  Technical  Data  to  be 
Supplied 

Technical  Data  Justification 
Code 

Reference  Number  Justification 
Code 

Service  Code 

Additional  User  Activity  1 
Service  Code 

Additional  User  Activity  2 
Service  Code 

Additional  User  Activity  3 
Service  Code 

Additional  User  Activity  4 
Service  Code 

Additional  User  Activity  5 
Service  Code 

Additional  User  Activity  6 
Service  Code 

Additional  User  Activity  7 
Advice  Code 

Various  Internal  Processing 
Dates 

Various  Internal  Processing 
Indicators 


Figure  VI-5 
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encountered  with  a  Part  Number  and  that  Part  Number  is  already 
under  process  by  this  application,  the  new  transaction  is 
assigned  the  same  Document  Number  as  the  transaction  already 
under  process  and  is  processed  concurrently  with  the  previous 
transaction.  For  example,  when  the  prior  transaction  is  being 
processed  in  the  functional  area,  the  new  transaction  and  all 
transactions  with  the  same  Part  Number  are  output  to  the  output 
products  file  for  printing  on  the  Provisioning  Control  File 
Interrogation  List  and  the  Provisioning  Part  Number  Select-NSN 
Request  Card  List.  These  lists  serve  as  functional  notification 
of  this  situation  and  the  new  transaction  is  highlighted  by  an 
asterisk  on  both  these  listings.  When  initial  advice  has  been 
sent  to  the  SICC  for  the  prior  SSR  transaction,  the  same  initial 
advice  is  automatically  provided  the  new  SICC  and  when  an  NSN  is 
assigned,  it  is  provided  automatically  to  both  SICCs.  The  new 
SSR  transaction  is  posted  to  the  SSR  Suspense  File;  however,  no 
DLSC  screening  transaction  is  prepared  unless  the  SSR  transac¬ 
tion  contains  an  NSN  Justification  code. 

( 2 )  DLSC  Screening  Replies 


As  described  in  the  System  Overview  above,  these 
transactions  are  initially  processed  by  the  Technical  and  Logis¬ 
tics  Services  Subsystem.  This  program  module  uses  the  replies 
to  complete  processing  for  some  items  and  to  initiate  functional 
processing  for  others.  When  the  DLSC  reply  indicates  no  match 
for  a  submitted  part  number,  match  to  PSCN,  or  multiple  NSNs  for 
a  submitted  part  number  with  an  NSN  Justification  Code,  or  sub¬ 
mitted  PSCN  found  in  DLSC  files;  the  DLSC  reply  is  used  to  update 
the  item  record  in  the  SSR  Suspense  File  and  to  initiate  func¬ 
tional  action  by  generating  skeleton  file  maintenance  transac¬ 
tions  and  records  to  be  printed  on  the  Provisioning  Part  Number 
Select  -  NSN  Request  Card  List.  These  skeleton  file  maintenance 
transactions  and  print  records  are  output  to  the  output  products 
file. 


Several  actions  are  automatically  taken  when 
the  DLSC  reply  indicates  the  NSN  was  found  in  DLSC  files  and  the 
IMC  Classification  process  was  successful.  The  item  record  is 
extracted  from  the  SSR  Suspense  File  and  updated  with  the  DLSC 
reply  information.  An  accept  advice  is  determined  from  the  AAC 
assignment  and  entered  in  the  item  record.  An  accept  advice 
transaction  is  generated  and  transmitted  to  the  SICC  via  AUTODIN. 
Print  records  for  the  Provisioning  Sensor  Report  and  Provision¬ 
ing  Advice  List  are  generated  and  output  to  the  output  products 
file.  When  the  AAC  indicates  the  item  is  stocked,  a  require¬ 
ments  transaction  is  generated  to  pass  SSR  requirements  to  the 
SAMMS  Requirements  Subsystem.  The  item  record  is  output  to  the 
History  Transactions  File. 
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Other  DLSC  Reply  transactions  are  used  by  this 
program  module  to  update  the  item  record,  and  generate  reject 
advice  to  the  SICC.  When  these  DLSC  replies  are  encountered, 
the  item  record  is  extracted  from  the  SSR  Suspense  File  and 
updated  with  data  from  the  DLSC  reply.  A  reject  advice  transac¬ 
tion  is  generated  using  data  from  the  DLSC  reply  to  determine 
the  appropriate  reject  advice  code  and  transmitted  via  AUTODIN 
to  the  SICC.  The  reject  advice  code  is  entered  in  the  item 
record  which  is  output  to  the  History  Transactions  File.  Print 
records  are  also  generated  and  output  to  the  Output  Products 
File  for  printing  the  Provisioning  Sensor  Report  and  the  Provi¬ 
sioning  Advice  List.  The  SSR  transactions  rejected  as  a  result 
of  DLSC  screening  include  Part  Numbers  which  matched  to  an  NSN 
or  multiple  NSNs  in  DLSC  files.  Part  Numbers  which  matched  to  a 
security  classified  item  in  DLSC  files,  NSNs  or  PSCNs  which  were 
cancelled  with  or  without  replacement,  NSNs  or  PSCNs  which  did 
not  match  DLSC  files,  and  NSNs  which  were  passed  to  the  I MC 
Classification  Application  and  the  resulting  cataloging  transac¬ 
tions  were  rejected  by  DLSC. 

(3)  File  Maintenance  Transactions 


As  discussed  above,  DLSC  replies  result  in 
generation  of  skeleton  file  maintenance  transactions  when  func¬ 
tional  processing  is  required  before  advice  is  forwarded  to  the 
SICC.  Functional  processing  results  in  completion  of  skeleton 
file  maintenance  transactions  which  are  then  input  to  the  SSR 
Subsystem  and  acted  upon  by  this  program  module.  File  Mainte¬ 
nance  transactions  may  be  used  to  accomplish  several  functions 
including  providing  advice  to  the  SICC,  interrogating  the  SSR 
Suspense  File  and/or  SSR  History  File,  changing  item  record 
data,  deleting  item  records  from  the  SSR  Suspense  File,  and  ini¬ 
tiating  DLSC  screening  on  the  SSR  item  submitted  or  for  an  NSN 
identified  in  the  file  maintenance  transaction.  The  particular 
function  to  be  performed  is  identified  through  the  use  of  an 
Action  Code  in  the  File  Maintenance  Transaction.  Each  File 
Maintenance  Transaction  is  validated  as  discussed  earlier.  When 
an  invalid  transaction  is  found,  it  is  output  to  the  output  pro¬ 
ducts  file  for  printing  on  the  Provisioning  Control  F/M 
Exceptions  List. 


When  functional  processing  identifies  an  invalid 
condition,  a  skeleton  file  maintenance  transaction  is  completed 
and  input  to  the  SSR  Subsystem.  This  file  maintenance  transac¬ 
tion  results  in  the  item  record  being  extracted  from  the  SSR 
Suspense  File.  The  reject  advice  code  is  determined  and  entered 
in  the  item  record.  A  reject  advice  transaction  is  generated  and 
transmitted  to  the  SICC  via  AUTODIN.  Print  records  are  generated 
and  output  to  the  output  products  file  for  printing  on  the  Pro¬ 
visioning  Sensor  Report  and  the  Provisioning  Advice  List.  The 
item  record  is  output  to  the  History  Transaction  File. 
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When  functional  processing  identifies  an  alter¬ 
nate  or  substitute  item  to  offer  the  SICC,  the  skeleton  file 
maintenance  transaction  is  completed  and  the  NSN  or  Part  Number 
of  the  offered  item  is  inserted.  The  offered  item  is  added  to 
the  SSR  Suspense  file  item  record  and  the  item  record  is  updated 
to  reflect  the  offer  advice  returned  to  the  SICC.  An  offer 
advice  transaction  is  generated  and  transmitted  to  the  SICC  via 
AUTODIN.  Print  records  are  generated  and  output  to  the  Output 
Products  File  for  printing  on  the  Provisioning  Sensor  Report  and 
the  Provisioning  Advice  List. 

When  functional  processing  determines  a  new 
item  is  to  be  accepted  for  support  and  requires  NSN  assignment 
from  DLSC,  the  skeleton  file  maintenance  transaction  is  completed 
and  input  to  the  SSR  Subsystem.  This  program  module  updates  the 
SSR  Suspense  File  item  record,  generates  an  initial  accept  advice 
transaction  and  transmits  the  advice  transaction  to  the  SICC  via 
AUTODIN.  The  accept  advice  code  is  determined  from  the  AAC 
assignment.  Print  records  are  generated  and  output  to  the  out¬ 
put  products  file  for  printing  on  the  Provisioning  Sensor  Report 
and  the  Provisioning  Advice  List  Catalog  transactions  containing 
MOE  Rule  and  Catalog  Management  Data  are  generated  and  output  to 
the  Catalog  Transactions  File.  These  transactions  are  forwarded 
to  the  SAMMS  Cataloging  Subsystem  and  become  part  of  the  NIIN 
Assignment  Request  transmitted  to  DLSC.  The  MOE  Rule  and  Cata¬ 
log  Management  Data  is  also  output  to  the  Output  Products  File 
for  printing  on  the  Segment  B  and  H  Data  from  Provisioning  List. 

During  functional  processing,  other  file  mainte¬ 
nance  actions  may  be  required.  Skeleton  file  maintenance  trans¬ 
actions  may  be  completed  and  used  to  change  data  in  the  item 
record  or  to  delete  the  item  record  from  the  SSR  Suspense  File. 
File  maintenance  transactions  may  also  be  used  to  initiate 
rescreening  of  the  item  submitted  or  to  initiate  screening  of  an 
item  in  the  file  maintenance  transaction.  File  maintenance 
transactions  may  also  be  used  to  interrogate  the  SSR  Suspense 
File  and  SSR  History  File.  Interrogations  may  be  submitted  on  a 
PCC,  on  an  item,  or  on  a  DLSC  Document  Number  basis.  When  the 
interrogation  is  on  an  item  or  a  DLSC  Document  Number  basis,  the 
SSR  Suspense  File  is  screened  for  the  item.  If  found,  selected 
item  data  is  output  to  the  output  products  file  for  printing  on 
the  Provisioning  Control  File  Interrogation  List.  If  not  found, 
the  interrogation  is  output  to  the  History  Transactions  File. 

When  the  interrogation  is  on  a  PCC  basis,  selected  data  for  item 
records  with  matching  PCC  is  extracted  from  the  SSR  Suspense 
File  and  output  to  the  output  products  file  for  printing  on  the 
Provisioning  Control  File  Interrogation  List.  The  interrogation 
is  then  output  to  the  History  Transactions  File. 
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(4 )  Offer  Reply  Transactions 

When  an  Offer  Reply  Transaction  Is  identified 
by  this  program  module,  It  Is  analyzed  to  determine  if  the  reply 
is  accept  or  reject.  When  the  offered  item  has  been  rejected, 
the  item  record  in  the  SSR  Suspense  File  is  updated  with  the 
reply  and  status  is  altered  to  indicate  the  item  is  awaiting  NSN 
assignment  from  DLSC  for  the  original  Part  Number.  Print  records 
for  the  reply  are  generated  and  output  to  the  Output  Products 
File  for  printing  on  the  Provisioning  Sensor  Report  and  the 
Provisioning  Advice  List.  Catalog  transactions  containing  MOE 
Rule  and  Catalog  Management  Data  are  generated  and  output  to  the 
Catalog  Transactions  File  and  this  data  is  also  output  to  the 
output  products  file  for  printing  on  the  Segment  B  and  H  Data 
from  Provisioning  List.  Item  record  data  is  also  output  to  the 
output  products  file  for  printing  or.  the  Provisioning  Part 
Number  Select-NSN  Request  Card  List.  This  item  is  highlighted 
with  an  asterisk  on  this  list  as  an  indication  that  this  is  not 
an  initial  appearance  of  the  item  on  the  list. 

Offer  replies,  indicating  acceptance  of  an  of¬ 
fered  item  with  an  NSN,  update  the  item  record  in  the  SSR  Suspense 
File  and  generate  print  records  to  the  Output  Products  File  for 
printing  on  the  Provisioning  Sensor  Report  and  Provisioning 
Advice  List.  Appropriate  cataloging  transactions  (e.g.,  add 
user)  are  generated  and  output  to  the  DLSC  Inquiries  File.  When 
the  AAC  of  the  item  record  indicates  the  item  is  stocked,  a  re¬ 
quirements  transaction  is  output  to  the  Requirements  Transactions 
File  to  pass  SSR  Requirements  to  the  SAMMS  Requirements  Subsystem. 

Offer  replies,  indicating  acceptance  of  an 
offered  item  with  a  Part  Number,  update  the  item  record  in  the 
SSR  Suspense  File  and  generate  print  records  to  the  Output  Pro¬ 
ducts  File  for  printing  on  the  Provisioning  Sensor  Report  and 
the  Provisioning  Advice  List.  A  DLSC  screening  transaction  for 
the  accepted  part  number  is  generated  and  output  to  the  DLSC 
Inquiries  File.  When  a  reply  is  received,  it  is  processed  as  any 
other  part  number  DLSC  Reply  described  above  with  one  exception. 

If  the  part  number  matches  to  an  NSN  in  DLSC  files,  a  reject 
advice  transaction  is  not  returned  to  the  SICC;  the  matched  NSN 
is  output  for  functional  action. 

(5)  DLSC  NSN  Assignments.  NSN  assignment  requests 
submitted  to  DLSC  are  processed  and  the  assigned  NSN  is  returned 
to  the  IMM.  These  NSN  Assignments  are  initially  processed  in 
the  Technical  and  Logistics  Services  Subsystem.  When  this 
program  module  identifies  one  of  these  assignments,  the  item 
record  is  extracted  from  the  SSR  Suspense  File.  Tl.e  item  record 
is  then  updated  with  the  assigned  NSN  and  an  NSN  Notification 
Transaction  is  generated  and  transmitted  to  the  SICC  via 
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AUTODIN.  Print  Records  are  generated  and  output  to  the  Output 
Products  File  for  printing  on  the  Provisioning  Sensor  Report  and 
the  Provisioning  Advice  List.  A  requirements  transaction  is 
generated  to  pass  SSR  requirements  to  the  SAMMS  Requirements 
Subsystem  and  a  Provisioning  Support  File  Record  is  generated 
and  posted  to  this  file.  The  item  record  is  output  to  the 
History  x'ransaction  File. 

( 6 )  Followup  Tr an s a c t i on s / Li s t ings  (Internal  and 

External) 


This  program  module  processes  followup  transac¬ 
tions  from  SICCs  and  monitors  the  progress  of  items  on  tiu?  SSR 
Suspense  File.  When  DLSC  Inquiries  are  generated,  a  suspense  of 
seven  days  is  placed  on  the  item  for  return  of  a  response.  If 
the  response  is  not  received  and  the  inquiry  was  for  an  NSN  or 
PSCN,  the  inquiry  is  regenerated  and  submitted  to  DLSC.  When  a 
response  to  the  resubmittal  for  NSNs  and  PSCNs  or  the  initial 
submittal  for  Part  Numbers  is  not  received  in  seven  days,  a  No 
Match  Reply  is  generated  and  processed  as  other  DLSC  Replies 
indicating  a  No  Match  condition.  When  a  No  Match  Reply  is  gener¬ 
ated  for  a  Part  Number,  a  print  record  is  output  to  the  Output 
Products  File  for  inclusion  in  the  Provisioning  Sensor  Report. 

Offer  advice  submissions  to  a  SICC  are  moni¬ 
tored  for  a  reply.  When  a  reply  is  not  received  after  30  days, 
a  record  is  output  to  the  output  products  file  for  printing  on 
the  Provisioning  30-Day  Followup  for  YL/YQ  Advice  List.  YL  and 
YQ  are  Action  Taken  Codes  (ATCs)  entered  in  an  offer  Advice 
Transactions  for  an  NSN  offer  and  a  part  number  offer  respec¬ 
tively.  After  45  days  a  record  is  again  output  to  the  Output 
Products  File  for  printing  on  the  Provisioning  45-Day  Followup 
for  YL/YQ  Advice  List  when  no  reply  has  been  received.  After  60 
days  have  passed  with  no  reply,  a  reject  advice  t'  ■  >saction  is 
generated  and  transmitted  to  the  SICC  via  AUTODIN.  The  item 
record  is  extracted  from  the  SSR  Suspense  File,  updated  with  the 
reject  advice  and  output  to  the  History  Transactions  File.  A 
print  record  is  generated  and  output  to  the  output  products  file 
for  printing  on  the  Provisioning  60  Day  Reject  YL/YQ  Advice  List. 

Item  records  are  monitored  to  ensure  advice  is 
furnished  to  the  SICC  on  a  timely  basis.  When  an  item  has  been 
on  the  SSR  Suspense  File  for  11  or  more  days  and  initial  advice 
has  not  been  furnished  to  the  SICC,  a  print  record  is  output  to 
the  Output  Products  File  for  printing  on  the  Part  I,  Provisioning 
Control  File  Aging  Report.  When  an  item  has  been  on  the  SSR 
Suspense  File  for  24  days  with  no  advice  furnished  the  SICC, 
another  print  record  is  output  to  the  Output  Products  File  and 
an  advice  transaction,  containing  ATC  '67'  (advice  pending)  is 
generated  and  transmitted  to  the  SICC  via  AUTODIN.  For  items 
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requiring  NSN  assignment,  a  comparison  is  made  between  the  cur¬ 
rent  date  and  the  Date  NSNs  Required  in  the  item  records.  When 
this  comparison  shows  the  item  will  become  delinquent  within  30 
days,  a  print  record  is  output  to  the  output  products  file  for 
printing  on  the  Part  II,  Provisioning  Control  File  Aging  Report. 
When  the  comparison  shows  the  item  is  delinquent,  a  record  is 
output  to  the  output  products  file  for  printing  on  the  Part  III, 
Provisioning  Control  File  Aging  Report. 

Followup  transactions  received  from  SICCs  are 
first  validated  for  format  and  content.  If  found  to  be  invalid, 
a  Followup  Response  Transaction  containing  ATC  '66'  (no  record) 
is  generated  and  transmitted  to  the  SICC  via  AUTODIN.  Valid 
transactions  are  matched  to  the  SSR  Suspense  File  based  on  ISN, 
DOR,  PCC,  and  ACF  with  no  matches  being  output  to  the  History 
Transactions  File.  When  a  match  is  found  on  the  SSR  Suspense 
File,  a  Followup  Response  Transaction  is  generated  and  trans¬ 
mitted  to  the  SICC  via  AUTODIN.  The  advice  code  in  the  Follow¬ 
up  Response  Transaction  reflects  the  advice  from  the  Item  record 
or  if  blank  in  the  item  record,  an  ATC  '67'  is  used. 

There  are  two  additional  processing  features  of 
this  program  module  which  require  explanation.  First,  whenever 
a  print  record  is  output  to  the  Output  Products  File  for  printing 
on  the  Provisioning  Sensor  Report,  an  identical  record  is  output 
to  the  Monthly  Output  Products  File  for  processing  in  the  Monthly 
SSR  Application.  Also,  whenever  an  item  record  is  extracted  from 
the  SSR  Suspense  File  and  output  to  the  History  Transactions  File, 
the  corresponding  records  on  the  Part  Numbe r /NS N / P SC N  to  Docu¬ 
ment  Number  Cross  Reference  File  and  the  Document  Number  to  Part 
Num be r / NS N/ PSCN  Cross  Reference  File  are  purged  from  these  files. 

d.  Outputs  .  There  are  several  outputs  from  this  program 
module  including  the  Updated  SSR  Suspense  File,  Advice  Transac¬ 
tions  File,  DLSC  Inquiries  File,  Closed  Loop  Suspense  File,  Out¬ 
put  Products  File,  History  Transactions  File,  Monthly  Output 
Products  File,  Catalog  Transactions  File,  and  Requirements  Trans¬ 
act  ions  File . 

(1)  Updated  SSR  Suspense  File.  This  file  replaces 
the  SSR  Suspense  File  used  in  this  daily  processing  cycle. 

(2)  Advice  Transactions  File.  This  file  contains 
accept,  offer,  and  reject  advice  transactions  as  well  as  NSN 
Notification  and  followup  reponse  transactions  for  AUTODIN  trans¬ 
mittal  to  SICCs. 

(3)  DLSC  Inquiries  File.  This  file  contains  DLSC 
screening  inquiries  to  be  transmitted  to  DLSC  for  processing. 
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(A)  Closed  Loop  Suspense  File.  This  file  contains 
a  record  of  transactions  submitted  to  DLSC  for  processing. 

(5)  Output  Products  File.  This  file  contains  re¬ 
cords  to  produce  functional  listings  and  skeleton  file  mainte¬ 
nance  transactions. 

(6)  History  Transactions  File.  This  file  contains 
transactions  to  be  processed  by  the  Weekly  SSR  Application. 

(7)  Monthly  Output  Products  File.  This  file  con¬ 
tains  records  to  be  processed  by  the  Monthly  SSR  Application. 

(8)  Catalog  Transactions  File.  This  File  contains 
transactions  to  be  combined  with  other  NSN  assignment  request 
transactions  in  the  SAMMS  Cataloging  Subsystem. 

(9)  Requirements  Transactions  File.  This  file  con¬ 
tains  transactions  used  by  the  SAMMS  Requirements  Subsystem  to 
include  SSR  requirements  in  forecasting  and  budgeting.  These 
transactions  may  initiate  procurement  action  as  a  result  of  pro¬ 
cessing  performed  in  the  SAMMS  Requirements  Subsystem. 

A .  SSR  Output  Generator 


a.  Inputs .  The  single  input  to  this  program  module  is 
the  Output  Products  File  generated  by  the  prior  program  modules 
in  the  Daily  SSR  Application. 

b.  Files .  No  files  are  accessed  by  this  program  module 


c.  Processing .  Processing  in  this  program  module  con¬ 
sists  of  sorting  records  from  the  Output  Products  File  into  func 
tional  product  sequence  and  producing  the  functional  products 
described  below. 

d.  Outputs .  There  are  several  outp  its  from  this  pro¬ 
gram  module  all  of  which  are  for  functional  use /not  if icat ion . 

(1)  Skeleton  File  Maintenance  Transactions.  These 
transactions  are  for  functional  use  in  providing  advice  to  the 
SICC  or  performing  up da t e s / in t e r r o g a t i on s  on  the  SSR  Suspense 
File  . 


(2)  Provisioning  PCC/High  Dollar  Review  List.  This 
list  contains  all  SSR  transactions  input  to  the  current  daily 
cycle.  The  total  dollar  value  of  these  transactions  appears 
when  it  is  more  than  $2,500.  A  sample  of  this  list  is  shewn  in 
Figure  VI-6. 
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Figure  Vl-6 


(3)  Provisioning  Input  Exceptions  List.  This  list 
contains  SSR  transactions  failing  validation  due  to  control  ele¬ 
ment  or  package  errors.  A  sample  of  this  list  is  shown  in 
Figure  VI- 7 . 


(4)  Provisioning  Control  F/M  Exceptions  List.  This 
list  contains  file  maintenance  transactions  which  were  found  to 
be  invalid.  A  sample  of  this  list  is  shown  in  Figure  VI-8. 

( 5 )  Provisioning  Design  Change  List  .  This  list 
contains  all  SSR  change  transactions  submitted  to  the  daily  pro¬ 
cessing  cycle.  A  sample  of  this  list  is  shown  in  Figure  VI-9. 

(6 )  Part  I,  Provisioning  Control  File  Aging  Report . 
This  is  a  list  of  items  which  have  been  on  the  SSR  Suspense  File 
for  more  than  11  days  without  advice  furnished  to  the  SICC.  A 
sample  of  this  list  is  shown  in  Figure  VI-10. 

(7 )  Part  II,  Provisioning  Control  File  Aging  Report . 
This  is  a  list  of  items  on  the  SSR  Suspense  File  which  require 
NSN  Assignment  and  will  become  delinquent  within  30  days  if  an 
NSN  is  not  assigned.  A  sample  of  this  list  is  shown  in  Figure 
VI-11. 

( 8 )  Part  III,  Provisioning  Control  File  Aging  Report  . 
This  list  contains  items  from  the  Part  II  listing  which  are 
delinquent.  The  format  of  this  list  is  similar  to  that  of  the 
Part  II  list. 

(9)  Provisioning  Sensor  Report.  This  report  con¬ 
tains  counts  of  actions  occurring  during  the  current  daily  pro¬ 
cessing  cycle.  A  sample  of  this  report  is  shown  in  Figure  VI-12. 

(10)  Provisioning  Control  Code/ Weapons  Systems 
Listing.  This  is  a  printout  of  the  P  CC / ACF  Table  from  the  Pro¬ 
visioning  Table  File.  The  format  for  this  listing  is  shown  in 
Figure  VI-13. 

(11)  Provisioning  Advice  List.  This  list  contains  a 
record  of  advice  transactions  generated  during  the  current  pro¬ 
cessing  cycle.  Followup  Response  Transactions  are  not  included. 

A  sample  format  for  the  report  is  shown  in  Figure  VI-14. 

(12)  Provisioning  SSR  List.  This  is  a  list  of  SSR 
transactions  initially  entering  the  Daily  SSR  Application  in  the 
current  cycle  and  not  having  a  control  element  or  package  vali¬ 
dation  error.  A  sample  format  of  this  list  is  shown  in  Figure 
VI-15. 
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Figure  VI-15 


(13)  Provisioning  Control  File  T" ter roga tion  List. 
This  Is  a  formatted  interrogation  orlaiout.  A  sample  format  of 
this  list  is  shown  in  Fi<””-_  Vi-16. 

1 1 4 )  Provisioning  30-Day  Followup  for  YL/Y Q  Advice . 
This  is  a  list  of  items  for  which  an  offer  reply  has  not  been 
received  within  30  days  of  providing  the  offer  to  the  SICC.  A 
sample  format  of  this  list  is  shown  in  Figure  VI-17. 

(15)  Provisioning  45-Day  Followup  for  YL/YQ  Advice. 
This  is  a  list  of  items  for  which  an  offer  reply  has  not  been 
received  within  45  days  of  providing  the  offer  to  the  SICC.  A 
sample  format  of  this  list  is  shown  in  Figure  VI-18. 

(16)  Provisioning  60-Day  Reject  YL/YQ  Advice.  This 
is  a  list  of  items  rejected  for  support  because  an  offer  reply 
was  not  received.  A  sample  format  for  this  list  is  shown  in 
Figure  VI-19. 

(17)  Provisioning  Part  Number  Select  -  NSN  Request 
Card  List.  This  is  a  list  of  the  skeleton  file  maintenance 
transactions  generated  in  the  current  processing  cycle.  A 
sample  format  of  this  list  is  shown  in  Figure  VI-20. 

(18)  SSRs  (Condition  2)  with  Nondefinitive  Unit  of 
Issue .  This  is  a  list  of  inactive  NSN  SSR  items  submitted  with 
nondefinitive  unit  of  issue.  The  format  for  this  list  is  shown 
in  Figure  VI-21. 

(19)  Segment  B  and  H  Data  from  Provisioning.  This 
is  a  formatted  print  of  MOE  Rule  ar d  Catalog  Management  Data 
passed  from  the  SSR  Subsystem  to  the  Catalog  Subsystem  for  use 
in  requesting  NSN  assignment  from  DLSC.  A  sample  of  this  list 
is  shown  in  Figure  VI-22. 

F .  DETAILED  WEEKLY  SSR  APPLICATION  DESCRIPTION 

This  paragraph  discusses  the  Weekly  SSR  Application  which 
consists  of  the  single  program  module  shown  in  Figure  VI-23. 

The  SSR  Weekly  File  Maintenance  Program  Module  shown  in  Figure 
VI-23  is  a  portion  of  the  SAMMS  SSR  Subsystem  shown  in  Figure 
VI-3.  This  Weekly  SSR  Application  is  scheduled  and  executed 
separately  from  the  Daily  and  Monthly  SSR  Applications.  The 
Weekly  SSR  Application  is  scheduled  once  per  week  and  operates 
in  a  batched  sequential  mode.  The  SSR  Weekly  File  Maintenance 
Program  Module  is  described  in  terms  of  inputs,  files,  pro¬ 
cessing  and  outputs. 


Figure  VI-17 


V* 


V 


Figure  VI-18 


0 


€ 

s* 


O'  O'  O'  ^ 

»— t  H  H  H 

8  8  8  8 


53  gr  8 


8 


Si 

iH 

r5 

oo 


ro 

5 


Si 


s 

a 


CM 

C? 


8 

Jn 


co 

o 


<r  m  ps-  ^ 

g  g  g  |  | 

m  lA  CM  CM 

§  s  s  a  s 

s  n  §  § 

3  3  3  3  3 


193 


SSRs  (CMCITION  2)  WITH  MMEFINITIVE  LNTT  OF  ISSUE  DATE  78160  PtfE  3 


Figure  VI-21 


1.  Input 8 .  The  single  input  to  this  program  module  is  the 
History  Transactions  File  from  the  Daily  SSR  Application.  This 
file  contains  file  maintenance  interrogations,  item  records  to 
be  added  to  the  SSR  History  File  and  followup  transactions  for 
which  no  matching  item  was  found  in  the  SSR  Suspense  File. 

2.  Files .  A  single  file  is  accessed  by  this  program  module. 
This  is  the  SSR  History  File.  This  file  is  identical  to  the  SSR 
Suspense  File  in  the  Daily  SSR  Application  except  that  the  SSR 
History  File  contains  item  records  for  which  final  advice  has 
been  furnished  to  the  SICC. 

3 .  Processing 

This  program  module  first  sorts  all  input  transactions 
based  on  sort  key.  Item  records  are  added  to  the  SSR  History 
File  and  the  current  date  is  placed  in  the  Record  Drop  Date.  In 
addition,  all  other  item  records  having  the  same  PCC,  ACF,  and 
DOR  have  their  Record  Drop  Dates  altered  to  reflect  the  current 
date  . 


Next,  followup  transactions  are  processed.  Each  follow¬ 
up  transaction  is  matched  to  the  SSR  History  File  based  on  sort 
key.  When  a  match  is  found,  a  Followup  Response  Transaction  is 
generated  using  the  ATC  in  the  item  record  and  output  to  the 
Advice  Transactions  File  for  transmittal  to  the  SICC.  When  a 
match  is  not  found,  a  Followup  Response  Transaction  containing 
an  ATC  '66'  (no  record)  is  generated  and  output  to  the  Advice 
Transactions  File  for  transmittal  to  the  SICC. 

File  maintenance  interrogations  are  matched  to  the  SSR 
History  File  next.  When  the  Interrogation  is  for  a  specific  ISN 
or  Document  Number  and  the  item  is  not  found,  the  interrogation 
is  printed  on  the  Provisioning  Control  F/M  Exception  List.  When 
the  item  is  found,  the  item  is  printed  on  the  Provisioning  Con¬ 
trol  File  Interrogation  List.  When  the  interrogation  is  for  all 
items  with  a  specific  PCC,  all  matching  items  are  printed  on  the 
Provisioning  Control  File  Interrogation  List.  When  no  matching 
items  are  found,  the  interrogation  is  dropped  if  matching  items 
were  found  in  the  Daily  SSR  Application  or  it  is  printed  on  the 
Provisioning  Control  F/M  Exception  List  when  no  matching  items 
were  found  either  in  the  SSR  Suspense  File  or  the  SSR  History 
File  . 


The  final  action  of  this  program  module  is  to  purge  all 
items  from  the  SSR  History  File  with  Record  Drop  Dates  over  one 
year  old . 

A.  Outputs.  There  are  three  outputs  from  this  program 
module.  These  are  the  Updated  SSR  History  File,  Advice  Trans¬ 
actions  File  and  Functional  Listings. 
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a.  Updated  SSR  History  File.  This  updated  file  will  be 
used  in  the  next  weekly  processing  cycle,  replacing  the  SSR 
History  File  used  in  the  current  cycle. 

b.  Advice  Transactions  File.  This  file  contains  fol¬ 
lowup  response  transactions  to  be  submitted  to  SICCs  via  AUTODIN. 

c.  Weekly  Functional  Listings.  There  are  two  func¬ 
tional  listings  produced  by  this  program  module  both  of  which 
were  described  in  the  Daily  SSR  Application  above. 

(1)  Provisioning  Control  File  Interrogation  List. 

(2)  Provisioning  Control  F/M  Exception  List. 

G .  DETAILED  MONTHLY  SSR  APPLICATION  DESCRIPTION 

This  paragraph  describes  the  Monthly  SSR  Application  which 
consists  of  a  single  program  module  as  shown  in  Figure  VI-24. 

The  SSR  Monthly  Output  Generator  shown  in  Figure  VI-24  is  the 
final  portion  of  the  SAMMS  SSR  Subsystem  shown  in  Figure  VI-3. 

The  Monthly  SSR  Application  is  scheduled  separately  from  the 
Daily  and  Weekly  SSR  Applications.  It  is  executed  once  per  month 
and  operated  in  a  batched  sequential  mode.  The  SSR  Monthly  Out¬ 
put  Generator  Program  Module  is  discussed  in  terms  of  inputs, 
files,  processing  and  outputs. 

1.  Inputs .  The  single  input  to  this  program  module  is  the 
Monthly  Output  Products  File.  This  file  contains  data  accumulated 
since  the  previous  monthly  processing  cycle. 

2.  Files .  No  files  are  accessed  by  this  program  module. 

3.  Processing  ■  Processing  in  this  program  module  consists 
of  accumulating  the  records  produced  on  a  daily  basis  and  pro¬ 
ducing  the  Provisioning  Sensor  Report. 


4.  Outputs .  The  single  output  from  this  program  module  is 
the  Provisioning  Sensor  Report  showing  monthly  activity  in  the 
SSR  Subsystem. 


CHAPTER  VII 


GENERAL  SERVICES  ADMINISTRATION 


A.  INTRODUCTION 

The  Logistics  Data  Management  (LDM)  System  is  a  standard  ADP 
system  used  within  the  General  Services  Administration  (GSA). 

This  is  a  new  system  within  GSA  under  which  automated  processing 
of  SSRs  is  being  developed.  This  new  LDM  System  will  replace 
the  current  cataloging  system  used  within  GSA  in  the  Federal 
Supply  Service  (FSS). 

B .  SYSTEM  DESIGN  PROCESS 

The  responsibility  for  processing  of  SSRs  within  GSA  is  in 
the  Office  of  Customer  Service  and  Support  within  the  Federal 
Supply  Service.  This  office  is  responsible  for  ensuring  effec¬ 
tive  logistics  support  is  provided  by  GSA  to  all  Federal  activ¬ 
ities.  The  decision  to  automate  SSR  processing  within  GSA  came 
with  the  implementation  of  the  IMM  Manual  and  revisions  to  the 
automated  portion  of  the  Federal  Catalog  Program.  Figure  VII-1 
illustrates  the  organizational  alignment  involved  in  the  design 
of  the  LDM  System.  The  development  of  the  LDM  System  is  the 
responsibility  of  one  section  within  the  Data  Management  Branch. 
This  section  develops  detailed  design  specifications  which  may 
be  used  to  develop  program  modules  by  computer  programmers. 

C .  SYSTEM  DOCUMENTATION 

A  functional  requirement  to  automate  SSR  processing  does  not 
exist  within  GSA.  The  automation  of  SSR  processing  was  included 
as  part  of  the  LDM  System  for  which  no  formal  Functional  Require¬ 
ments  Description  was  developed.  The  Data  Management  Branch 
developed  a  Detail  System  Design  Specification  for  the  LDM  Sys¬ 
tem.  This  Detailed  System  Design  Specification  breaks  the  total 
system  down  into  processing  segments  by  type  of  input  transac¬ 
tion  and  contains  input  formats,  file  structures,  generalized 
processing  flow  charts  and  detail  logic  flow  charts  and  decision 
tables  to  document  processing  criteria  such  as  validation  of 
Input  transactions.  Documentation  to  be  developed  beyond  this 
level  and  the  actual  programming  activity  is  unknown. 

D  .  LDM  SYSTEM  DESIGN  OVERVIEW 

The  LDM  System  is  designed  to  automate  processing  of  IMC 
transactions,  SSR  transactions,  and  Requests  for  Federal  Cata¬ 
loging/Supply  Support  Action  from  Civil  Agencies;  and  to  provide 
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automation  of  GSA  involvement  in  the  Inactive  Item  Program  and 
the  Automatic  User  Registration  Program.  The  features  of  the 
LDM  System  as  related  to  SSR  processing  are  described  in  terms 
of  inputs,  files,  processing  and  outputs  as  contained  in  the 
Detailed  System  Design  Specification.  Figure  VII-2  shows  the 
specific  inputs,  files  and  outputs  to  be  discussed. 

1.  Inputs.  There  are  five  SSR  related  inputs  to  this  sys¬ 
tem.  These  are  Incoming  SSR  transactions,  advice  transactions, 
Followup  transactions,  Offer  Reply  transactions,  and  local 
inquiries  . 

a.  Incoming  SSR  Transactions.  These  are  SSR  transac¬ 
tions  mailed  by  SICCs  to  GSA  for  processing. 

b.  Advice  Transactions.  These  are  manually  generated 
advice  transactions  for  transmittal  to  SICCs. 

c.  Followup  Transactions.  These  are  transactions  mailed 
or  transmitted  via  AUTODIN  by  SICCs  requesting  status  on  pre¬ 
viously  submitted  SSR  transactions. 

d.  Offer  Reply  Transactions.  These  are  transactions 
from  SICCs  replying  to  offer  advice  transactions  from  GSA. 

e.  Local  Inquiries.  These  are  manually  generated 
inquiries  to  the  Federal  Logistics  Data  File  (FLDF),  the  Catalog 
Action  Monitor  File  (CAMF)  and  the  SSR  Suspense  File. 

2.  Files .  There  are  three  files  used  in  processing  SSR 
transactions  within  the  LDM  System.  These  are  the  Federal 
Logistics  Data  File,  the  Catalog  Action  Monitor  File  and  the  SSR 
Suspense  File. 

a.  Federal  Logistics  Data  File  (FLDF).  This  sequential 
magnetic  tape  file  contains  logistics  data  for  items  managed  by 
GSA.  It  is  structured  similar  to  the  DLSC  DIDSTIR  File  and  is 
sequenced  on  NSN. 

b.  Catalog  Action  Monitor  File  (CAMF).  The  CAMF  is  the 
primary  active  control  and  suspense  file  within  the  LDM  System. 
This  is  a  sequential  magnetic  tape  file  with  sequential  control 
based  on  an  internal  Document  Serial  Control  Number  (DSCN)  estab¬ 
lished  by  GSA.  Each  item  posted  to  the  CAMF  consists  of  several 
90-character  records.  An  SSR  item  posted  to  this  file  will  con¬ 
sist  of  a  control  record,  a  basic  record  (both  of  these  contain 
information  for  internal  GSA  use),  an  expanded  CWA  record,  ex¬ 
panded  CXA/ B / C / F / G/ K  records  and  expanded  advice  and  Offer  Reply 
records.  Followup  transactions  and  Followup  Response  transac¬ 
tions  are  not  posted  to  this  file.  Completed  items  are  purged 
from  the  CAMF  on  a  monthly  basis. 
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c.  SSR  Suspense  File.  This  file  is  a  magnetic  tape 
file  sequenced  on  Activity  Code  From,  Date  of  Request,  Provision 
ing  Control  Code  and  Item  Serial  Number.  This  file  is  termed 
the  SSR  Master  Cross  Reference  File  by  GSA  and  serves  as  a  cross 
reference  between  SSR  controls  and  DSCN,  and  serves  as  a  history 
of  SSR  transactions  processed.  Each  SSR  item  is  posted  to  this 
file  as  a  single  45  character  record.  The  data  elements  con¬ 
tained  in  each  record  include: 

Activity  Code  From 
Date  of  Request 
Provisioning  Control  Code 
Item  Serial  Number 
Date  to  Group 

Type  Request  (Provisioning,  Nonprovisioning, 
Change ) 

Type  Change  Code 

Document  Serial  Control  Number 

Date  of  Transaction 

Assigned  NSN/PSCN 

Action  Taken  Code 

Records  are  purged  from  this  file  on  a  monthly  basis  two  years 
from  the  Date  To  Group,  which  is  the  date  the  item  entered  this 
file  . 

3 .  Processing 

The  L DM  System  is  designed  to  process  all  types  of  in¬ 
coming  SSR  transactions  including  provisioning,  nonprovisioning, 
and  change  SSR  transactions.  Subsequent  to  an  initial  package 
check,  each  item  is  processed  independently  of  all  other  items. 
There  are  no  processing  priorities  within  the  LDM  System;  how¬ 
ever,  the  design  includes  extensive  mechanical  processing  of 
some  SSR  transactions,  while  others  must  be  manually  processed. 

The  LDM  System  is  designed  around  processing  cycles 
rather  than  type  of  transaction,  program  or  function.  The  pro¬ 
cessing  cycles  Include  daily,  weekly,  monthly,  quarterly  and 
semiannual  cycles  with  SSR  processing  concentrated  in  the  daily, 
weekly  and  monthly  cycles.  The  LDM  System  is  designed  to  pro¬ 
cess  DLSC  screening  transactions;  however,  no  DLSC  screening 
transactions  are  automatically  generated  from  SSR  transactions, 
and  if  DLSC  screening  transactions  are  manually  generated,  the 
system  design  includes  no  direct  interface  between  DLSC  reply 
and  SSR  transaction  processing. 

The  SSR  transactions  are  first  subjected  to  a  PCC  pack¬ 
age  check  after  which  the  entire  PDSSR  transaction  is  validated. 
The  system  design  calls  for  validation  until  the  first  error  is 
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encountered  and  automatic  generation  of  reject  advice  transac¬ 
tions  when  an  error  is  encountered.  Error  transactions  are  also 
printed  on  an  error  list.  The  PCC  package  is  split  into  item 
packages  based  on  the  ISN  when  the  PCC  package  and  PDSSR  trans¬ 
action  is  valid.  If  invalid,  processing  is  terminated  on  the 
package  as  a  whole,  subsequent  to  generating  reject  advice  trans¬ 
actions  and  printing  the  entire  PCC  package  on  the  Error  List. 

Each  item  package  and  individual  SSR  transaction  is 
next  validated.  When  an  error  is  encountered,  a  reject  advice 
transaction  is  generated  for  the  item  and  the  item  package  is 
printed  on  the  error  list.  SSR  Suspense  File  records  are  gener¬ 
ated  for  each  item  package  whether  valid  or  invalid.  Records 
are  also  generated  to  update  the  FLDF  and  CAMF . 

Some  item  packages  will  continue  automated  processing 
and  others  are  output  for  manual  processing.  It  appears  that 
automated  processing  continues  for  NSN  items  and  includes  update 
of  the  FLDF,  automatic  generation  of  accept  advice  transactions 
and  automatic  generation  of  catalog  transactions  (e.g.,  Add  User 
Transactions)  for  submittal  to  DLSC.  Other  SSR  items  are  output 
on  a  Functional  Notification  List  for  manual  advice  determination. 
SSR  change  transactions  containing  Type  Change  Code  'S'  are  pro¬ 
cessed  as  initial  submittals.  Other  SSR  change  transactions  are 
output  on  the  Notification  List  for  manual  action.  When  a  man¬ 
ually  generated  advice  transaction  is  introduced  to  the  System, 
it  is  validated  and  used  to  update  the  SSR  Suspense  File  and 
CAMF  . 


Offer  Reply  Transactions  received  by  GSA  and  input 
to  the  LDM  System  are  used  to  update  the  SSR  Suspense  File  and 
CAMF.  These  transactions  are  also  output  on  the  Notification 
List  for  functional  user  action. 

Followup  transactions  input  to  this  System  are  pro¬ 
cessed  against  the  SSR  Suspense  File.  The  Action  Taken  Code  to 
be  placed  in  the  followup  response  transaction  is  based  on  a 
match/no  match  condition  and  the  Advice  Code  In  the  SSR  Suspense 
File  record  for  matches.  Followup  response  transactions  are 
automatically  generated  and  output  for  transmittal  to  the  SICC. 

A  record  of  followup  transactions  received  and  Followup  Response 
Transactions  generated  is  not  maintained  in  the  System,  and  no 
functional  notification  is  produced  to  inform  the  functional 
user  that  a  followup  has  been  received. 

The  CAMF  maintains  internal  suspenses  on  each  item 
package  which  may  result  in  generation  of  advice  transactions. 
When  initial  advice  for  an  item  has  not  been  provided,  an  interim 
advice  transaction  will  be  automatically  generated.  Also  when 
offer  advice  is  overdue  from  a  SICC,  a  reject  advice  transaction 
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will  automatically  be  generated.  No  functional  notifications 
are  produced  when  these  actions  are  taken;  however,  on  a  weekly 
basis  a  CAMF  Status  Report  is  produced  giving  the  status  of  each 
DSCN  on  the  CAMF.  When  these  advice  transactions  are  generated, 
transactions  are  also  generated  to  update  the  SSR  Suspense  File 
record  with  this  advice  in  the  next  daily  cycle. 

Inquiries  may  be  manually  generated  to  obtain  data 
from  the  FLDF,  the  CAMF  or  the  SSR  Suspense  File.  These  inquiries 
are  processed  on  a  daily  basis. 

4.  Outputs .  There  are  five  related  outputs  from  the  LDM 
System  as  shown  in  Figure  VI1-2.  These  outputs  include  Advice 
transactions.  Followup  Response  transactions,  Catalog  transac¬ 
tions,  SSR  Suspense  File  updates  and  functional  outputs. 

a.  Advice  Transactions.  Advice  transactions  for  trans¬ 
mittal  to  the  SICC  may  be  produced  as  cards  for  mailing  or  as  a 
magnetic  tape  for  AUTODIN  transmittal. 

b.  Followup  Response  Transactions.  These  transactions 
may  be  produced  as  cards  for  mailing  to  SICCs  or  as  magnetic 
tape  for  AUTODIN  transmittal. 

c.  Catalog  Transactions.  These  are  transactions  for 
AUTODIN  transmittal  to  DLSC  to  update  DLSC  files. 

d.  SSR  Suspense  File  Updates.  These  transactions  are 
generated  to  provide  the  advice  returned  to  SICCs  to  the  SSR 
Suspense  File  for  history  retention. 

e.  Functional  Outputs.  There  are  several  functional 
outputs  produced  by  the  LDM  System  some  of  which  are  listed 
below . 


(1)  Error  List  .  This  list  contains  SSR  transac¬ 
tions  found  to  be  in  error  by  the  System. 

(2)  Notification  List.  This  is  a  list  of  items 
which  generally  require  some  manual  processing  action  to  be 
taken . 

(3)  SSR  Review  Notification.  This  is  a  sample  of 
the  type  of  functional  listings  included  in  this  system  design. 

A  format  of  this  list  is  shown  in  Figure  VII-3. 

(4)  SSR  File  Inquiry  Reply.  A  format  for  this  list 
is  shown  in  Figure  VII-4  and  illustrates  the  type  of  reply 
received  from  SSR  Suspense  File  inquiries. 

(5)  SSR  Transaction  Summary.  A  format  for  this  list 
is  shown  in  Figure  VII-5  and  illustrates  the  type  of  counts  main¬ 
tained  in  the  System. 
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PART  2 
OPERATIONAL 
IMPLEMENTATION 


CHAPTER  I 


INTRODUCTION 


The  automated  systems  design  of  each  of  the  Components  was 
presented  In  Part  I  of  this  Volume.  These  automated  systems 
perform  many  of  the  major  events  within  the  processing  phases 
pictured  In  the  Conceptual  Systems  Model  (Figure  1-1).  This 
Chapter  uses  the  Conceptual  Systems  Model  as  a  base  for  present¬ 
ing  the  operational  systems  in  use  at  the  time  of  the  Operational 
Implementation  Review. 

Since  the  degree  of  Implementation  of  the  automated  systems 
design  varies  at  the  operational  activities  reviewed,  a  section 
at  the  beginning  of  each  Component  Chapter  discusses  the  imple¬ 
mentation  status  of  the  automated  system  design  at  each  activity 
visited.  In  addition,  the  automated,  operational  system  currently 
in  use  is  presented  to  the  extent  that  it  interfaces  or  differs 
from  the  systems  design  presented  in  Part  1.  The  organizational 
structure  of  the  activity  reviewed  within  each  Component  is  pre¬ 
sented  next  and  centers  around  only  those  organizational  elements 
involved  with  performing  the  major  events  from  the  Conceptual 
Systems  Model.  The  operational  systems  of  each  activity  are  then 
presented  as  a  combination  of  manual  and  automated  actions  leading 
to  and  including  generation  and  processing  of  SSR  transactions. 

For  Components  which  act  as  SICCs,  the  generation  and  processing 
of  outgoing  provisioning  SSR  transactions  is  discussed  separately 
from  outgoing  nonprovisioning  SSR  transactions.  The  processing 
performed  by  the  Services  for  incoming  SSR  transactions  is  gener¬ 
ally  limited  to  Active  NSN  SSR  transactions  only.  The  specific 
reasons  for  this  are  discussed  on  a  Service  basis.  The  processing 
performed  on  incoming  SSR  transactions  by  CIMM  Component  activ¬ 
ities  is  generally  divided  into  three  subsections.  One  subsection 
each  is  devoted  to  Active  NSN  SSR  processing,  Inactive  NSN/PSCN 
SSR  processing,  and  Part  Number  SSR  processing.  Honconsumable 
Item  Materiel  Support  Request  (NIMSR)  generation  and  processing 
by  the  Services  is  discussed  on  a  more  general  basis  as  the  final 
Chapter  of  Part  2 . 

In  the  automated,  operational  system  discussions  presented 
in  this  Part,  the  same  type  of  system  chart  is  used  as  those  used 
used  in  Part  1.  However,  in  the  discussion  of  the  operational 
systems,  two  types  of  charts  are  used.  First,  the  operational 
system  being  described  is  presented  on  an  Operational  SSR  System 
Chart  which  depicts  the  processing  performed  in  terms  of  major 
events  within  phases  and  is  similar  to  the  Conceptual  Systems 
Model  Chart.  This  Operational  SSR  System  Chart  provides  the 
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specific  major  events  and  processing  phases  performed  at  the 
activity  reviewed.  In  addition,  SSR  Work  Flow  Charts  were 
developed  for  each  Operational  SSR  System.  These  SSR  Work  Flow 
Charts  show  the  relationship  between  processing  phases,  major 
events,  actions  or  subevents  and  the  specific  organizational 
element  performing  each  action  or  subevent.  A  sample  Work  Flow 
Chart  is  shown  in  Figure  1-2.  As  shown  by  this  figure,  there 
are  two  phases  involved  in  the  Work  Flow  as  diagrammed.  Phase  I 
consists  of  two  major  events  while  Phase  II  consists  of  three 
major  events.  The  relationships  between  the  subevents  and  the 
organizational  element  performing  each  subevent  is  shown  through 
the  use  of  symbols.  These  symbols  are  shown  at  the  top  of  each 
work  flow  chart  and  include: 

Circle  (Q)  -  Processing  Action 

Square  ( [~]  )  -  START  or  STOP  Processing  Action 

Lined,  Inverted  Triangle  (^)  -  History  File  Action 

Inverted  Triangle  (V?  )  ~  Suspense/Cont  rol  File  Action 
Arrow  (Q)  -  Page  Connectors 

As  shown  in  Figure  1-2,  processing  is  begun  by  Organizational 
Element  1  by  performing  subevent  1  of  major  event  1  of  Phase  I. 
Subevent  2  of  major  event  1  of  Phase  I  is  an  action  performed  by 
Organizational  Element  2.  Line  and  arrow  connectors  are  used  to 
show  the  direction  of  work  flow  from  subevent  to  subevent  and 
organizational  element  to  organizational  element.  The  work  flow 
continues  through  a  final  history  file  action  by  Organizational 
Element  1  in  subevent  2  of  major  event  3  of  Phase  II.  The  sub- 
paragraphs  of  the  text  applying  to  each  work  flow  chart  contain 
the  same  prefixed  letter  or  number  annotation  as  that  preceding 
the  corresponding  phase,  major  event  or  subevent  in  the  work  flow 
chart.  This  ties  the  text  and  chart  together  for  referencing 
purposes  . 
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A .  I  NTRODUCTION 

The  five  Materiel  Readiness  Commands  (MRCs)  under  the  Com¬ 
modity  Command  Standard  System  (CCSS)  are  the  primary  Army  activ¬ 
ities  involved  in  SSR  generation  and  processing.  Under  the  opera¬ 
tional  implementation  phase  of  research,  two  of  these  MRCs  were 
visited;  t  ti  e  U.S.  Army  Tank-Automotive  Materiel  Readiness  Command 
(TARCOM)  and  the  U.S.  Army  Troop  Support  and  Aviation  Materiel 
Readiness  Command  (TSARCOM).  TARCOM  was  included  because  of  its 
unique  mission  of  serving  as  a  CIMM  for  certain  DoD  mission 
classes.  TSARCOM  was  included  to  review  SSR  processing  from  a 
SICC/WIMM  basis  as  the  Army  prototype  for  the  CCSS  SSR  Applica¬ 
tion  (Phase  I)  implementation. 

This  Chapter  first  presents  the  Army  automated  operational 
system  being  used  at  TSARCOM  during  this  research  phase.  The 
organizational  elements  involved  in  SSR  generation  and  processing 
at  TSARCOM  are  presented,  followed  by  discussion  of  SICC  provi¬ 
sioning  SSR  generation  and  processing,  SICC  non p ro v i s ioni ng  SSR 
generation  and  processing  and  WIMM  SSR  processing.  This  is  fol¬ 
lowed  by  a  presentation  of  the  organizational  elements  involved 
with  CIMM  SSR  processing  and  a  discussion  of  CIMM  SSR  processing 
.it  TARCOM. 

B •  ARMY  AUTOMATED  OPERATIONAL  SYSTEM  DESCRIPTION 

1.  implementation  Status.  The  SSR  Application  was  designed, 
developed  and  implemented  in  two  phases.  Phase  I  was  distributed 
by  AEMSA  for  implementation  at  all  the  MRCs  concurrently  as 
scheduled  in  May  1978.  Phase  II  was  scheduled  for  concurrent 
implementation  at  all  the  MRCs  In  April  1979.  The  study  team 
visits  to  Armv  operating  activities  occurred  in  July  and  August 
1978.  Since  Phase  I  does  not  produce  SSR  cards  itself  each  MRC 
had  to  develop  a  local  Interface  which  generally  consisted  of  a 
program  modulo  to  produce  SSR  cards  and  a  listing  from  the  out¬ 
put  SSR  transaction  file  from  Phase  I.  The  automated  portions 
or  SSR  Generation  and  Processing  that  were  operational  during 
the  operational  Implementation  review  at  TSARCOM  are  shown  in 
Figure  I  I  —  1  .  This  figure  serves  a  dual  purpose  in  showing  the 
automated  interfaces  discussed  in  Part  1  of  this  Volume  that 
were  in  operational  status  during  the  Operational  Implementation 
Review  and  in  introducing  a  local  MRC  addition  to  the  SSR  Appli¬ 
cation  which  was  also  operational.  The  Provisioning  Subsystem, 

End  Item  Parameter  Update  Application,  Part  Number  Screening 
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Part  Number  Screening  Application,  Automated  Requirements  Computa 
tion  Application  and  SSR  Converter  Program  Module  are  all  part 
of  CCSS  and  were  discussed  in  Part  I  of  the  Volume.  Figure  1 1  —  1 
shows  that  TSARCOM  developed  two  automated  processes  that  inter¬ 
faces  with  the  CCSS  SSR  Application  (Phase  I);  a  Sort,  Extract, 
Print/Punch  Program  Module  and  a  Technical  Data  Support  Support 
Tracking  Application. 

2.  Sort,  Extract,  Print/Punch  Program  Module.  This  program 
module  was  designed,  developed,  and  programmed  by  TSARCOM  to  put 
the  SSR  transactions  generated  by  the  CCSS  SSR  Converter  Program 
Module  into  a  functionally  usable  form.  It  sequences,  prints 
and  punches  SSR  transactions  for  functional  use. 

a.  Inputs.  The  single  input  to  this  program  module  is 
the  SSR  transactions  residing  on  magnetic  tape  (or  disk)  from 
the  CCSS  SSR  Converter  Program  Module. 

b.  Files.  There  are  no  files  accessed  by  this  program 

module  . 

c.  Processing.  This  program  module  sorts  all  input 
transactions  into  PCC,  ACT,  ISN  and  DIC  sequence.  It  then  prints 
these  transactions  on  a  listing  and  produces  two  duplicate  EAM 
card  decks  containing  these  transactions.  One  deck  is  for  the 
functional  user  to  mail  to  the  appropriate  I  MM  s ;  the  second  deck 
is  for  input  to  the  Technical  Data  Support  Tracking  Application. 

d .  Outputs 

(1)  Outgoing  SSR  Cards/List.  One  deck  of  the  SSR 
Cards  and  the  List  is  forwarded  to  the  Data  Management  Branch 
(DMB)  within  the  Directorate  for  Materiel  Management  (DMM). 

(2)  Technical  Data  SSR  Cards.  The  second  deck  of 
SSR  Cards  is  input  to  the  Technical  Data  Support  Tracking  Appli- 
cat ion . 

3 .  Technical  Data  Support  Tracking  Applicaion .  This  appli¬ 
cation  was  designed  and  developed  by  TSARCOM  to  provide  an  auto¬ 
mated  method  of  providing  followups  to  the  Technical  Data 
Repository  for  submission  of  technical  data  promised  to  IMMs. 

a .  Inputs 


(1)  File  Maintenance  Transactions.  These  transac¬ 
tions  update  the  suspense  on  SSR  transactions  located  on  the 
Technical  Data  SSR  File.  These  transactions  may  also  be  used 
to  delete  SSR  transactions  from  the  file. 
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(2)  Technical  Data  SSR  Cards.  These  are  transac¬ 
tions  generated  In  the  previous  program  module. 

b.  Flies  .  The  Technical  Data  SSR  File  is  accessed  by 
this  program  module.  This  is  a  sequential  magnetic  tape  file 
containing  SSR  transactions  requiring  technical  data  to  be  sub¬ 
mitted  to  the  IMM  when  received  by  the  Technical  Data  Repository 
from  the  contractor.  This  file  is  sequenced  on  ACT,  PCC,  DOR, 

JN  and  DIC,  and  consists  primarily  of  PDSSR  transactions,  LISSR 
transactions  containing  a  part  number,  item  name  transactions 
and  additional  reference  transactions  with  a  16-position  sort 
key  appended  to  each. 

c.  Processing.  The  Technical  Data  SSR  cards  input  to 
this  program  module  are  first  appended  with  a  16-position  sort 
key  and  are  then  sorted  based  on  this  sort  key.  Next,  each 
LISSR  transaction  package  is  checked  to  determine  if  technical 
data  has  been  promised  for  that  item.  The  check  is  made  using 
the  Document  Availability  Code,  the  Technical  Data  Justification 
Code  and  the  Dace  Technical  Data  to  be  Supplied  in  the  LISSR 
transaction  package.  When  Technical  Data  SSR  cards  meet  the 
criteria  for  technical  data  submission,  outgoing  SSR  cards  and 
technical  data  owed  followup  cards  are  generated.  These  LISSR 
transaction  packages  are  also  logged  on  the  Technical  Data  SSR 
File.  The  cards  generated  are  for  use  by  the  Technical  Data 
Repository  and  will  be  discussed  later  in  this  section.  When 
LISSR  transaction  packages  reside  on  the  Technical  Data  SSR  file; 
periodically,  based  on  the  Date  Technical  Data  to  be  Supplied  or 
at  45-day  intervals,  a  new  set  of  outgoing  SSR  cards  and  Tech¬ 
nical  Data  Owed  Followup  cards  are  automatically  generated.  File 
maintenance  transactions  may  be  input  to  this  program  module  to 
update  the  suspense  or  delete  transactions  from  this  file. 

d  .  Outputs 

(1)  Technical  Data  SSR  File.  This  is  an  updated 
file  to  replace  the  one  used  in  this  processing  cycle. 

(2)  Outgoing  SSR  Cards.  These  are  SSR  transactions 
to  be  combined  with  promised  technical  data  and  mailed  to  an 

IMM  . 

(3)  Technical  Data  Owed  Followups.  These  are 
Internal  followups  to  the  Technical  Data  Repository. 

(4)  Functional  Reports.  There  are  basically  three 
reports  output  by  this  program  module.  First,  a  list  of  SSR 
transactions  on  the  Technical  Data  SSR  File  is  printed.  Second, 
selected  counts  of  transactions  processed  during  the  cycle  are 
produced.  Finally,  a  quarterly  report  of  SSR  transaction  counts 
by  ACT  is  produced. 
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C.  SICC/WIMM  ORGANIZATIONAL  STRUCTURE 


Each  MRC  is  responsible  for  item  selection,  SM&R  coding  and 
IMC  during  provisioning  efforts.  This  responsibility  Includes 
method  of  management  decisions  indicating  which  items  will  be 
retained  for  management  by  the  Provisioning  MRC,  which  consumable 
items  require  SSRs  to  be  sent  to  a  support  MRC  or  other  CIMM/WIMM 
and  which  reparable  items  require  NIMSRs  to  be  sent  to  a  support 
MRC  or  lead  ICP.  For  retained  items  and  items  submitted  to  the 
MRC  as  a  WIMM,  the  method  and  level  of  support  determinations 
are  made.  Although  each  of  the  MRCs  have  these  responsibilities, 
the  particular  organizational  structure  within  these  MRCs  under 
which  these  responsibilities  are  carried  out  differ.  Therefore, 
the  SICC/WIMM  organizational  structure  discussed  here  reflects 
that  found  at  TSARCOM. 

The  particular  organizational  elements  within  TSARCOM  in¬ 
volved  in  SSR  generation  and/or  processing  are  the  Integrated 
Logistics  Support  Office  (ILSO),  the  Directorate  for  Procurement 
and  Production  (DPP),  the  Directorate  for  Maintenance  (DM),  Direc 
torate  for  Management  Information  Systems  (DMIS),  the  Directorate 
for  Materiel  Management  (DMM),  and  the  Communications-Electronics 
Office.  Each  of  these  directorate  level  organizations  have  sub¬ 
elements  involved  with  SSR  generation  or  processing  and  are 
depicted  in  Figure  II-2.  Each  of  these  directorate  level  orga¬ 
nizations  will  now  be  discussed  in  turn  in  regard  to  specific 
SSR  related  functions  and  responsibilities. 

1  .  Integrated  Logistics  Support  Office  (ILSO).  The  Initial 
Provisioning  Management  Branch  within  the  Integrated  Logistics 
Support  Management  Division  performs  functions  related  to  SSR 
generation.  This  branch  prepares  and  coordinates  a  Provisioning 
Program  Plan  which  outlines  initial  provisioning  and  support 
item  milestones  and  scheduled  completion  dates.  It  also  assigns 
Provisioning  Contract  Control  Numbers  (PCCNs)  and  Provisioning 
Control  Codes  (PCCs)  to  be  used  in  each  initial  provisioning 
effort.  Collection  and  initial  processing  of  mission  support 
plans  submitted  by  field  activities  is  also  the  branch's  respon¬ 
sibility. 

2.  Directorate  for  Procurement  and  Production  (DPP).  This 
directorate  has  two  primary  areas  of  responsibility  related  to 
SSR  generation  and  processing.  The  first  of  these  is  to  review 
the  PTD  submitted  by  the  contractor  for  compliance  with  contrac¬ 
tual  requirements.  This  responsibility  includes  the  function  of 
performing  contract  surveillance  and  administration  as  the  Pro¬ 
curing  Contracting  Officer,  and  conducting  technical  conferences 
to  review  PTD  accuracy  and  adequacy.  The  second  responsibility 
involves  actions  on  procurement  of  items  to  support  SSR  require¬ 
ments,  both  internal  and  external,  as  initiated  by  the  require¬ 
ments  determination  process. 
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3.  Directorate  for  Maintenance  (DM).  There  are  five  division 
level  organizational  elements  within  the  Directorate  for  Mainte¬ 
nance  involved  in  SSR  generation  and  processing.  These  are  shown 
in  Figure  II-2  and  include  the  Administrative  Office,  the  Engi¬ 
neering  Support  Division  and  three  Maintenance  Management  Divi¬ 
sions  ■ 


a.  Administrative  Office.  The  Automated  Systems  Support 
Branch  within  this  office  functions  as  the  automated  data  pro¬ 
cessing  interface  between  this  directorate  and  the  Directorate 
for  Management  Information  Systems  (DMIS).  As  such,  this  branch 
maintains  card  punch  and  verifying  equipment  to  support  computer 
and  AUTODIN  operations.  This  branch  also  prepares  data  for 
transcribing,  card  punching  and  release  to  DMIS  for  automated 
processing . 


b.  Maintenance  Management  Divisions.  There  are  three 
Maintenance  Management  Divisions  within  the  Directorate  for 
Maintenance.  Each  of  these  divisions  consists  of  two  or  more 
systems/equipment  branches  performing  identical  SSR  related 
functions.  It  is  in  these  branches  where  provisioning  pro¬ 
cessing  within  this  Directorate  is  performed.  When  a  Provision¬ 
ing  Contracting  Officer  (PCO)  is  assigned  in  one  of  these  Divi¬ 
sions,  the  PTD  accuracy  and  adequacy  review  responsibility  is 
passed  from  DPP  to  personnel  in  these  branches.  The  range  and 
quantity  selection  of  support  items  and  SM&R  coding  takes  place 
in  these  branches.  Additional  maintenance  data  (e.g.,  failure 
factors)  are  assigned  in  these  branches  also.  The  establishment 
and  maintenance  of  the  CCSS  provisioning  files  and  maintenance 
data  on  the  local  TIR  File  is  the  responsibility  of  these 
branches.  These  branches  are  generally  responsible  for  monitor¬ 
ing  the  provisioning  effort  at  the  MRC  from  receipt  of  the  PTD 
until  support  status  is  determined. 

c.  Engineering  Support  Division.  This  division  con¬ 
sists  of  several  branches,  seven  of  which  are  involved  in  SSR 
generation  and  processing.  The  seven  branches  consist  of  six 

S ys t era/ Equi pmen t  Branches  and  a  General  Engineering  Branch.  The 
personnel  in  these  branches  are  generally  termed  equipment  spe¬ 
cialists  and  have  technical  expertise  in  system  configuration 
and  equipment  design.  The  primary  SSR  related  function  performed 
in  this  division  is  the  review  of  offers  made  by  the  IMMs  and 
deciding  if  the  offered  item  is  acceptable. 

4.  Directorate  for  Management  Information  Systems.  There 
are  two  Division  level  organizational  elements  in  this  Directorate 
performing  functions  related  to  SSR  generation  and  processing. 
These  are  the  Computer  Management  Division  and  the  Technical 
Information  Division. 
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a.  Technical  Information  Division.  The  Technical  In¬ 
formation  Division  is  responsible  for  reviewing  technical  data 
(e.g.,  drawings,  aperture  cards)  included  in  the  PTD  submitted 
by  contractors  for  adequacy,  accuracy  and  currency.  It  must 
also  maintain  a  library  of  current  technical  data  much  of  which 
is  stored  on  aperture  cards.  The  Technical  I  r.  £  oi  wc  t  i  on  Reposi¬ 
tory  is  a  branch  level  organization  within  this  division  which 
acts  on  technical  data  followups  from  the  Technical  Data  Support 
Tracking  Program  Module  discussed  in  Section  B.  above. 

b.  Computer  Management  Division.  The  Computer  Manage¬ 
ment  Division  if.  responsible  for  scheduling,  executing  and  main¬ 
taining  CCSS  an J  local  MRC  subsystems  and  applications.  Addi¬ 
tional  functions  of  this  division  include  providing  keypunch 
support  to  the  MRC  for  input  to  the  automated  subsystems/appli¬ 
cations  maintained  by  the  MRC  and  distributing  automated  outputs 
to  the  appropriate  functional  Directorates. 

5.  Directorate  for  Materiel  Management  (DMM).  There  are 
four  division  level  organizational  elements  within  this  Direc¬ 
torate  involved  with  SSR  related  processing.  The  division  level 
organizations  are  the  Administrative  Office,  the  Logistics  Data 
Management  Division,  and  two  Item  Management  Systems  Divisions. 

a.  Administrative  Office.  The  ADP  Input  Branch  within 
this  Office  provides  card  punch  and  verifying  services  to  the 
Directorate  as  well  as  serving  as  the  Directorate  interface  to 
the  DMIS  for  computer  support. 

b .  Logistics  Data  Management  Division 

This  division  is  the  principle  SSR  processor  and  con¬ 
sists  of  four  cataloging  branches  and  a  Data  Management  Branch. 
This  division  performs  all  cataloging  actions  for  the  MRC  and 
each  branch  is  made  up  of  cataloging  personnel.  Within  the 
cataloging  branches  some  catalogers  may  perform  dual  functions. 
Each  cataloger  is  assigned  a  group  of  FSCs  over  which  he  has 
responsibility  for  performing  catalog  actions.  In  addition,  a 
cataloger  may  be  assigned  to  monitor  cataloging  actions  for  all 
support  Items  within  a  particular  end  item.  In  this  report,  a 
cataloger  performing  normal  actions  related  to  a  support  item  is 
termed  a  FSC  cataloger;  when  performing  actions  related  to  an 
end  item,  he  is  termed  an  E/I  Cataloger. 

The  E/l  Cataloger  tunctions  related  to  SSR  genera¬ 
tion  include  assigning  FSC  for  new  items,  initiating  the  Auto¬ 
mated  Requirements  Computation  Application  for  provisioning 
items,  reviewing  provisioning  subsystem  and  automated  require¬ 
ments  computation  application  outputs,  and  initiating  follow-on 
actions  related  to  these  outputs.  The  E/I  cataloger  also  reviews 
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outputs  from  the  SSR  Applications.  He  reviews  and  receives 
approval  from  the  Item  Manager  before  submission  of  SSR  transac¬ 
tions  falling  under  the  high  dollar  breakout  program,  and  reviews 
rejected  SSR  candidates  to  initiate  NIMSR  action  or  manual  cor¬ 
rection  and  generation  of  SSR  transactions.  He  also  receives 
Item  requests  from  field  activites  and  initiates  catalog  data 
screening  of  these  items  to  determine  if  nonprovisioning  SSR 
transactions  should  be  generated  or  these  items  should  be  re¬ 
tained  for  MRC  management.  All  SSR  Advices  are  reviewed  by  the 
E/I  cataloger. 

The  FSC  cataloger  performs  IMC  assignment  for  new 
items  and  MCN  assignment.  He  prepares  Federal  Item  Identifica¬ 
tions  (Fils)  and  formats  NUN  requests  for  new  items  retained  for 
management  by  the  MRC.  The  FSC  cataloger  assigns  other  catalog¬ 
ing  data  required  to  manage  the  item  and  updates  items  or  estab¬ 
lishes  new  items  on  the  local  TIR  File.  The  FSC  cataloger  also 
provides  WIMM  cataloging  actions;  e.g.,  generating  Add  User 
Transactions  . 

The  Data  Management  Branch  ( DMB )  has  significantly 
different  responsibilities  under  SICC  and  WIMM  processing.  SICC 
functions  of  this  branch  include  preparing  and  keypunching  re¬ 
quest  cards  to  initiate  processing  in  the  Automated  Requirements 
Computation  Application;  preparing  and  mailing  outgoing  SSR 
transactions  with  associated  technical  data  and  Offer  Reply  Trans¬ 
actions;  establishing  and  maintaining  a  manual  file  of  SSRs  sub¬ 
mitted,  completed  and  rejected;  providing  followup  action  on 
overdue  advice  for  outgoing  SSR  transactions;  and  manually  for¬ 
matting  and  keypunching  offer  reply  transactions  and  resubmit¬ 
tals  of  outgoing  SSR  transactions  initially  rejected. 

WIMM  functions  performed  by  this  branch  include 
manual  validation  of  incoming  SSR  transactions  and  offer  replies; 
initiating  catalog  data  screening,  determining  initial  advice; 
establishing  and  maintaining  history  files  of  incoming  SSR  trans¬ 
actions  received  and  processed;  responding  to  followup  transac¬ 
tions  from  a  SICC,  formatting,  keypunching  and  mailing  advice 
transactions  to  the  SICC;  and  providing  notification  to  the  FSC 
cataloger,  item  manager  and  the  DM  of  incoming  SSR  transactions 
for  which  accept  advice  was  returned. 

c .  Item  Management  Systems  Divisions 

There  are  two  item  management  Systems  Divisions  with¬ 
in  DMM ,  each  of  which  consists  of  two  or  more  branches  made  up 
of  item  managers.  These  item  managers  are  responsible  for  estab¬ 
lishing  data  on  the  End  Item  Parameter  File  from  the  mission 
support  data  submitted  by  field  activities.  Retail  and  wholesale 
requirements  are  manually  computed  by  these  item  managers  for 
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items  not  processed  through  the  Automated  Requirements  Computa¬ 
tion  Application.  During  the  provisioning  process,  item  managers 
assign  inventory  management  data  such  as  AAC  (actual  or  recom¬ 
mended)  to  support  items. 

Specific  WIMM  functions  of  the  item  manager  are 
determination  of  method/level  of  support,  revision  of  accept 
advice  decision,  and  adjustment  of  stock  levels  and  initiation 
of  procurement  action  to  support  SSR  requirements. 

6.  Communication  Electronics  Office.  This  office  provides 
fixed  signal  AUTODIN  and  local  message  distribution  for  the 
command.  It  prepares  and  transmits  record  communications;  trans- 
ceives  data  pattern  messages  card  and  magnetic  tape;  and  opera¬ 
tes  the  IBM  S360/30  AUTODIN  Multimedia  Terminal  resident  at  the 
command . 

D.  ARMY  OUTGOING  PROVISIONING  SSR  GENERATION  AND  PROCESSING 


The  Army  Outgoing  Provisioning  SSR  Operational  System  exist¬ 
ing  at  TSARCOM  is  illustrated  in  Figure  II-3.  This  operational 
system  begins  at  the  time  a  provisioning  requirement  is  estab¬ 
lished  and  extends  until  support  is  accepted  by  an  IMM  or  pro¬ 
vided  by  the  provisioning  MRC.  This  figure  breaks  the  system 
down  into  its  processing  phases  and  the  major  events  within 
these  phases.  The  discussion  following  is  based  on  specific 
subevents  within  these  major  events  and  phases.  The  relation¬ 
ship  between  these  subevents,  major  events  and  processing  phases, 
and  the  organizational  elements  performing  them  is  illustrated 
by  the  Army  Outgoing  Provisioning  SSR  Work  Flow  Chart  (Figure 
II-4).  All  items  entering  this  operational  system  receive  equal 
cons i de ra t i on ;  i,e.,  there  are  no  processing  priorities  for  spe¬ 

cific  types  of  items.  Also  this  system  acts  to  generate  intra¬ 
service  as  well  as  interservice  SSR  transactions.  This  system 
is  not  set  up  to  process  Design  Change  Notices  (DCNs)  of  any 
type  . 

At  TSARCOM,  DCNs  are  processed  on  a  case  by  case  basis  with 
no  specific  procedures  available,  meaning  that  changes  to  pre¬ 
viously  submitted  SSRs  are  generated  on  a  manual  basis  only. 

1 •  Pr e p r o v i s i on i ng  Processing  Phase 

a .  Establish  Provisioning  Performance  Schedule 

(1)  By  the  time  a  provisioning  contract  is  awarded, 
a  Provisioning  Program  Plan  setting  milestones  for  the  comple¬ 
tion  of  provisioning  events  is  developed  by  the  Integrated  Logis¬ 
tics  Support  Office  (ILSO).  The  ILSO  assigns  the  Provisioning 
Contract  Control  Numbers  (PCCNs)  and  the  Provisioning  Control 
Codes  (PCCs)  to  be  used  during  the  actual  provisioning  effort. 
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Figure  II 
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(2)  The  PCCN  is  Chen  entered  in  the  PMR  File  so 
that  when  the  PTD  is  received  from  the  contractor  it  may  be  pro¬ 
cessed  by  the  CCSS  Automated  Provisioning  Subsystem.  After 
completion  of  these  actions,  ILSO  notifies  the  Directorate  for 
Maintenance  (DM)  and  the  Directorate  for  Materiel  Management 
(DMM)  of  the  PCCNs  and  PCCs  assigned  to  the  end  item  being  pro¬ 
visioned. 

2 •  Contractor  Processing  Phase 
a .  Prepare  PTD 


(1)  Contractor  Processing  normally  consists  of  pre¬ 
paration  and  submission  of  documentation  to  TSARCOM  as  EAM  cards, 
magnetic  tape  or  selection  worksheets.  Technical  Data  is  gener¬ 
ally  submitted  on  aperture  cards,  but  may  be  transmitted  as  hard 
copy  drawings.  The  contractor  submits  the  PTD  to  the  Directorate 
of  Procurement  and  Production  (DPP),  or  to  the  DM  if  a  Provision¬ 
ing  Contract  Officer  (PCO)  has  been  appointed,  and  it  is  here 
that  the  provisioning  processing  phase  at  TSARCOM  begins. 

(2)  Provisioning  Screening  is  generally  not  a  con¬ 
tractual  requirement  at  TSARCOM  and  therefore  is  not  performed 
by  the  contractor. 

3.  Provisioning  Processing  Phase.  There  are  seven  major 
events  within  this  phase  as  shown  in  Figure  II-3:  PMR  File 

Establishment,  Catalog  Data  Screening,  SM&R,  EIP  File  Establish¬ 
ment,  IMC ,  File  Maintenance  and  Requirements  Determination. 

a.  PMR  File  Establishment.  The  six  subevents  in  this 
major  event  are  illustrated  in  Figure  II-4. 

(1)  Provisioning  Technical  Documentation  is  received 
at  TSARCOM  by  the  DPP  or  the  PCO  within  the  DM.  This  documenta¬ 
tion  is  reviewed  for  compliance  with  contract  requirements  with 
discrepancies  being  resolved  with  the  contractor.  When  received 
and  reviewed  by  the  DPP,  the  PTD  is  forwarded  to  DM  when  complete 
If  receipt  and  review  is  done  by  the  DM  or  when  received  from 
the  DPP,  all  drawings  and  aperture  cards  are  separated  from  the 
PTD  and  forwarded  to  the  Technical  Information  Division  (TID). 

(2)  The  Technical  Information  Division  reviews  the 
drawings  and  aperture  cards  for  accuracy  and  currency. 

(3)  If  new  technical  data  or  updated  data  is  sub¬ 
mitted  for  an  item,  the  data  is  reproduced  on  microfilm  and 
transferred  to  an  aperture  card.  The  reproductions  are  filed  in 
the  automated  technical  library.  The  originals  are  returned  to 
the  DM  to  aid  in  further  processing  of  the  provisioning  package. 
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(4)  PTD  received  as  selection  worksheets  are  key¬ 
punched  into  standard  EAM  cards  in  preparation  for  input  to  the 
CCSS  Automated  Provisioning  Subsystem.  PTD  received  as  EAM  cards 
or  magnetic  tape  require  no  further  preparation.  The  cards  on 
magnetic  tape  are  input  to  CCSS  by  the  Computer  Management  Divi¬ 
sion  (CMD). 


(5)  The  Computer  Management  Division  inputs  auto¬ 
mated  provisioning  data  into  the  CCSS  Provisioning  Subsystem 
where  it  is  validated  for  format  and  content.  When  all  provi¬ 
sioning  data  is  found  to  be  valid  for  an  item,  it  is  added  to 
the  PMR  File.  If  invalid,  the  provisioning  data  is  returned  to 
DM  as  error  transactions  and  must  be  corrected  prior  to  reinput. 

(6)  This  correction  process  may  be  done  in  the  DM, 
or  the  PTD  in  error  may  be  returned  to  the  contractor  for  correc¬ 
tion  and  resubmittal.  Mechanized  selection  worksheets  containing 
contractor  furnished  data  are  output  by  the  Provisioning  Subsys¬ 
tem  for  those  items  added  to  the  PMR  File  for  manual  completion. 
In  addition,  part  number  screening  transactions  are  generated 

for  part  numbered  items  entering  the  PMR  File. 

b .  Catalog  Data  Screening 


(1)  Since  DLSC  screening  is  generally  not  required 
of  the  contractor  before  submittal  of  PTD,  most  items  in  the  PTD 
are  identified  by  manufacturers  FSCM  and  part  number.  Each  item 
identified  by  part  number  only,  is  screened  against  the  REFNO 
Fiie  as  discussed  in  Part  I  of  this  Volume  and  a  local  TIR  'n- 
quiry  or  a  DLSC  screening  inquiry  is  generated. 

(2)  Local  TIR  inquiries  extract  selected  data  on 
the  local  TIR  File  and  feed  this  data  to  the  provisioning  su  - 
system.  The  provisioning  subsystem  outputs  this  data  in  hard 
copy  and  it  is  forwarded  to  the  DM  for  use  in  the  next  pro¬ 
cessing  event. 

(3)  DLSC  Screening  Inquiries  are  forwarded  >  DLSC 
by  the  Communications  Center  over  AUTODIN.  When  replies  j.*e 
received  from  DLSC  they  are  recorded  on  magnetic  tape  and  for¬ 
warded  to  DMIS  for  input  to  the  Part  Number  Screening  Applicatior. 
Output  from  this  application  is  forwarded  directly  to  DMM  to  be 
matched  with  the  rest  of  the  provisioning  data  when  received 

from  DM  for  further  processing. 

c.  SM&R .  This  major  event  consists  of  the  four  sub¬ 
events  performed  in  DM  shown  in  Figure  II-4. 

(1)  When  items  have  automated  selection  worksheets 
output,  they  require  manual  addition  of  data  before  the  provi¬ 
sioning  subsystem  can  continue  automated  processing.  The  DM 
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uses  the  contractor  provided  data  automatically  entered  on  the 
selection  worksheets,  the  technical  data  provided  by  the  con¬ 
tractor  and  the  results  of  local  TIR  screening  to  enter  required 
maintenance  data  (e.g.,  failure  factors)  on  the  selection  work¬ 
sheets  . 

(2)  The  DM  also  determines  and  assigns  the  Source, 
Maintenance,  and  Recoverability  Codes  at  this  time.  The  items 
are  then  split  into  two  distinct  groups;  one  group  contains 
items  with  a  source  code  not  in  the  "P  "  series  (Procured);  the 
second  group  contains  items  that  are  source  coded  in  the  "P  " 
series  . 


(3)  The  nonsource  coded  "P”  items  continue  pro¬ 
cessing  in  the  DM.  The  DM  completes  the  item  selection  worksheets 
and  keypunches  this  data  into  ADP  cards  which  are  input  to  the 
provisioning  subsystem  by  the  Computer  Management  Division.  These 
cards  serve  as  file  maintenance  transactions  to  update  the  PMR 
File. 


(4)  Item  selection  worksheets,  contractor  furnished 
technical  data  and  local  TIR  screening  results  for  ”P_”  source 
coded  items  are  forwarded  to  DMM  for  I MC  coding.  These  items 
may  become  SSR  candidates  while  those  processed  in  DM  are  either 
retained,  or  support  will  be  requested  via  NIMSRs. 

d.  EIP  File  Establishment.  There  are  four  subevents 
shown  in  Figure  II-4  included  in  this  major  event.  This  event 
parallels  the  SM&R  coding  event.  While  the  DM  is  performing  the 
actions  described  in  the  previous  major  event,  the  actions  des¬ 
cribed  in  this  major  event  occur. 

(1)  Under  the  Army  philosophy  of  provisioning,  each 
field  activity  is  required  to  determine  its  end  item  require¬ 
ments  and  delivery  schedule  to  support  its  assigned  mission. 

These  requirements  are  prepared  in  the  form  of  mission  support 
plans  and  submitted  to  the  ILSO  of  the  provisioning  activity. 

(2)  The  ILSO  determines  when  all  mission  support 
plans  have  been  received  and  combines  these  plans  into  a  single 
package  of  end  item  requirements  data.  This  data  is  forwarded  to 
the  assigned  end  item  manager. 

(3)  The  end  item  manager  reviews  the  end  item  data 
package  and  converts  this  data  to  a  series  of  end  item  parame¬ 
ters  which  are  keypunched  into  EAM  cards. 

(4)  The  cards  are  input  to  the  EIP  Update  Applica¬ 
tion  by  the  Computer  Management  Division  to  establish  this  data 
on  the  End  Item  Parameter  File.  This  data  is  used  later  by  the 
CCSS  ARCSIP  Application  in  the  computation  of  requirements  and 
in  adding  program  data  to  SSR  candidates. 
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e.  IMC.  There  are  five  subevents  within  this  major 

event  . 

(1)  When  the  selection  worksheets,  local  and  DLSC 
Screening  results,  and  technical  data  are  received  in  the  Logis- 
tisc  Data  Management  Division,  the  end  item  is  assigned  to  a 
cataloger  based  on  the  FSC  of  the  end  item.  This  end  item  cata- 
loger  breaks  the  information  down  to  a  support  item  basis, 
assigns  the  Federal  Supply  Classification  (FSC)  for  new  items, 
establishes  manual  controls  on  each  item  and  forwards  items  to 
the  responsible  FSC  cataloger,  i.e.,  all  items  in  FSC  1510  are 
given  to  the  cataloger  responsible  for  FSC  1510  for  further  pro¬ 
cessing.  The  manual  controls  established  are  relatively  informal, 
but  aid  the  end  item  cataloger  in  tracking  each  item  through  its 
processing  cycle  within  DMM. 

(2)  The  FSC  cataloger  reviews  each  item  to  deter¬ 
mine  the  appropriate  Item  Manager  for  the  item.  This  may  be  the 
provisioning  MRC  ,  another  MRC  ,  another  Service  ICP,  a  DSC  or 
GSA.  After  this  determination  has  been  made  and  the  proper  IMC 
code  has  been  entered  on  the  selection  worksheet,  a  Management 
Control  Number  (MCN)  is  assigned  for  new  part  numbered  items  and 
entered  on  the  selection  worksheet.  Also,  any  other  cataloging 
information  required  is  registered. 

(3)  The  selection  worksheets,  screening  results, 
and  technical  data  are  returned  to  the  end  item  cataloged  who 
reviews  the  selection  worksheets  for  complete  cataloging  data, 
updates  his  control  file  and  forwards  the  item  packages  to  the 
appropriate  item  manager. 

(4)  The  item  manager  reviews  each  item  forwarded  to 
him  and  enters  inventory  management  data  on  the  selection  work¬ 
sheets;  e.g.,  AAC .  Completed  selection  worksheets  are  returned 
fo  the  end  item  cataloger. 

(5)  The  end  item  cataloger  reviews  each  item  selec¬ 
tion  worksheet  for  completeness  only  -  not  validity.  Those  found 
to  be  incomplete  are  returned  to  the  FSC  cataloger  or  item  manager 
for  completion.  Item  selection  worksheets  that  are  complete  are 
returned  to  the  DM  for  file  maintenance  processing.  The  informal 
control  file  is  updated  by  the  end  item  cataloger  as  each  item 

is  completed.  This  manual  file  serves  as  a  record  of  completed 
and  open  items.  The  end  item  cataloger  retains  the  drawings  and 
aperture  cards  and  disposes  of  screening  results  at  this  pro¬ 
cessing  point  . 

f.  File  Maintenance.  Four  subevents  are  included  in 
this  major  event. 
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(1)  The  selection  worksheets  are  again  reviewed  for 
completeness  in  the  DM. 

(2)  When  complete,  each  selection  worksheet  is  key¬ 
punched  into  a  series  of  EAM  card  transactions.  The  selection 
worksheets  are  retained  by  the  DM  as  a  history  record  of  completed 
items . 

(3)  me  punched  card  transactions  are  input  to  the 
provisioning  subsystem  as  PMR  file  update  transactions.  The  pro¬ 
visioning  subsystem  validates  these  transactions  for  format  and 
content  with  valid  transactions  used  to  add  provisioning  data  to 
the  PMR  and  local  TIR  files.  Invalid  entries  are  rejected  as 
errors  and  must  be  corrected  and  reinput  for  processing.  The 
major  output  products  of  the  CCSS  Provisioning  Subsystem  at  this 
point  are  the  ARCSIP  data  file,  the  PTD  History  Transaction  List 
and  the  File  Maintenance  Reject  List.  The  ARCSIP  data  file  con¬ 
tains  required  data  for  provisioning  items  on  which  automated 
requirements  computations  are  to  be  performed.  The  PTD  History 
Transaction  List  is  used  by  the  DM  and  the  end  item  cataloger  to 
determine  the  number  of  completed  items  in  the  PMR  File  by  pro¬ 
visioning  package.  The  File  Maintenance  Reject  List  is  used  by 
the  DM  and  end  item  cataloger  to  identify  invalid  data  which 
must  be  corrected  and  reinput. 

(4)  The  DM  reviews  the  PTD  History  Transaction  List 
and  the  File  Maintenance  Reject  List  when  received.  The  PTD 
History  Transaction  List  is  kept  with  the  selection  worksheets 
as  a  history  of  items  completed.  The  File  Maintenance  Reject 
List  is  reviewed  to  determine  if  DM  is  responsible  for  any  of 
the  invalid  data  entries.  If  so,  the  correct  information  is 
determined  and  coded  for  keypunch  and  reinput  to  the  CCSS 
Provisioning  Subsystem. 

When  these  lists  are  received  by  the  end  item  cata¬ 
loger  they  are  reviewed.  File  Maintenance  Rejects  are  reviewed 
to  determine  if  the  invalid  data  was  generated  by  the  FSC  cata¬ 
loger  or  the  inventory  manager  and,  if  so,  that  individual  is 
contacted  for  the  correct  information.  The  valid  data  is  coded 
and  forwarded  to  the  DM  for  keypunch  and  reinput  to  the  CCSS 
Provisioning  Subsystem.  The  PTD  History  Transaction  List  is 
retained  by  the  end  item  cataloger  as  a  history  of  completed 
items  on  the  PMR  File  by  PCC. 

g.  Requirements  Determination.  This  major  event  com¬ 
pletes  the  Provisioning  Processing  Phase  and  consists  of  four 
subevents • 

(L)  When  about  80%  of  the  items  on  the  file  for  a 
particular  provisioning  package  are  complete,  the  end  item  cata¬ 
loger  prepares  a  Disposition  Form  to  the  Data  Management  Branch 
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within  DMM  to  execute  the  CCSS  Automated  Requirements  Computa¬ 
tion  Application.  In  addition,  the  drawings  and  aperture  cards 
for  that  provisioning  package  are  forwarded  to  the  Data  Manage¬ 
ment  Branch  ( DMB ) . 

(2)  Upon  receipt  of  the  Disposition  Form  requesting 
a  run  of  the  CCSS  Automated  Requirements  Computation  Application, 
the  Data  Management  Branch  formats  and  keypunches  an  ARCSIP 
Request  Card.  This  card  is  input  to  the  CCSS  Automated  Require¬ 
ments  Computation  Application  by  the  Computer  Management  Divi¬ 
sion.  The  drawings  and  aperture  cards  are  filed  to  await  SSR 
transactions  generated  by  the  SSR  Converter  Program  Module. 

(3)  The  CCSS  Automated  Requirements  Computation 
Application  uses  the  ARCSIP  Request  card  to  control  which  items 
are  to  be  selected  from  the  ARCSIP  Data  File  for  Requirements 
Computations.  These  items  are  extracted  and  checked  for  complete 
data.  If  incomplete,  they  are  rejected  on  the  Incomplete  Data 
for  ARCSIP  List.  Wholesale  and  Retail  Quantities  to  meet  Pro¬ 
visioning  Requirements  are  computed  and  Initial  Supply  Control 
Studies  and  the  ARCSIP  Computation  Report  are  produced  for  com¬ 
plete  items.  Items  that  meet  SSR  generation  criteria  are  passed 
to  the  SSR  candidate  file  for  input  to  the  CCSS  SSR  Application. 

(A)  The  DM  receives  a  copy  of  the  Incomplete  Data 
for  ARCSIP  List  and  reviews  the  list  to  determine  if  the  incom¬ 
plete  data  is  maintenance  data.  If  so,  the  required  data  is 
coded,  keypunched  and  input  to  the  CCSS  Automated  Provisioning 
Subsystem  as  PMR  File  Update  transactions.  The  end  item  cata- 
loger  also  receives  a  copy  of  the  Incomplete  Data  for  ARCSIP 
List  as  well  as  the  ARCSIP  Computation  Report  and  Supply  Control 
Studies.  He  determines  incomplete  materiel  management  data  and 
contacts  the  responsible  FSC  cataloger  and/or  item  manager  to 
obtain  the  required  data.  The  data  is  formatted,  keypunched, 
and  input  to  the  CCSS  Automated  Provisioning  Subsystem  as  PMR 
File  Update  transactions  by  the  Computer  Management  Division. 

When  the  corrections  have  entered  the  PMR  File  as  shown  by  the 
PTD  History  Transaction  List,  a  disposition  form  is  prepared 
requesting  the  CCSS  Automated  Requirements  Computation  Applica¬ 
tion  be  run  for  these  items. 

The  ARCSIP  Computation  Report  is  used  to  track  those 
Items  which  have  had  wholesale  and  retail  quantities  computed  in 
a  PCC  package.  The  supply  control  studies  are  divided  into  two 
groups  by  the  end  item  cataloger;  those  which  are  for  items  to 
be  locally  managed  and  those  which  are  for  items  to  be  managed 
by  another  activity.  Supply  Control  Studies  for  items  to  be 
managed  locally  are  forwarded  to  the  inventory  managers  who  will 
be  managing  these  items  for  their  use.  Supply  Control  Studies 
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for  Items  to  be  managed  by  other  activities  are  reviewed  for 
high  dollar  breakout  limits  by  the  end  item  cataloger.  All  items 
exceeding  $1,000  per  unit  of  issue  must  be  reviewed  by  the  item 
manager  before  SSR  transactions  are  mailed  to  the  IMMs. 

4.  SICC  SSR  Processing  Phase.  This  processing  phase 
consists  of  three  major  events  as  shown  in  Figure  II-3:  Edit/ 
Validation,  File  Maintenance  and  Technical  Data  Tracking. 

a.  Edit/Validation.  This  major  event  consists  of 
the  two  subevents  shown  in  Figure  II-4. 

(1)  The  SSR  Candidate  File  generated  by  the 
CCSS  Automated  Requirements  Computation  Application  during  the 
Provisioning  Processing  Phase  is  fed  directly  into  the  CCSS  SSR 
Converter  Program  Module.  The  CCSS  SSR  Converter  Program  Module 
does  a  minimal  amount  of  validation  on  SSR  Candidate  transac¬ 
tions,  but  essentially  serves  to  format  SSR  data  into  PDSSR, 
LISSR,  and  Catalog  data  transactions.  SSR  candidates  found  to 
be  invalid  are  output  for  manual  correction. 

(2)  Invalid  SSR  Candidate  Transactions  generally 
consist  of  two  types  of  items;  those  that  are  nonconsumable  items 
managed  by  another  Service  or  those  that  contain  invalid  SSR 
data.  These  invalid  transactions  are  reviewed  by  the  end  item 
cataloger  who  initiates  a  NIMSR  for  nonconsumable  items  or  deter¬ 
mines  the  correct  SSR  data  and  manually  formats  and  keypunches 
the  SSR  transactions  to  be  mailed  to  the  IMM.  The  keypunched 
transactions  are  forwarded  to  the  Data  Management  Branch  for 
mailing  and  file  maintenance  action. 

b.  File  Maintenance.  This  major  event  is  made  up  of 
three  subevents. 

(1)  As  discussed  above,  SSR  transactions  generated 
by  the  SSR  Converter  Program  Module  are  input  to  a  locally  devel¬ 
oped  program  module  to  print  and  punch  the  transactions  for 
mailing  to  the  IMM  or  support  MRC .  The  SSR  transaction  cards 
and  the  Outgoing  SSR  List  are  forwarded  to  the  Data  Management 
Branch  for  processing.  The  technical  data  cards  are  passed 
directly  to  the  locally  developed  technical  data  tracking  appli¬ 
cation. 


(2)  The  SSR  transactions  produced  manually  by  the 
end  item  cataloger  and  those  generated  mechanically  are  pro¬ 
cessed  identically  by  the  Data  Management  Branch.  The  drawings 
and  aperture  cards  on  file  in  the  Data  Management  Branch  are 
joined  with  the  SSR  transactions  to  which  they  apply.  When 
there  is  an  Item  Name  transaction  in  the  LISSR  transaction  pack¬ 
age  and  technical  data  is  present,  the  Item  Name  transaction  is 


discarded  since  both  are  not  required  by  the  IMM  Manual.  The 
SSR  transactions  and  associated  technical  data  are  split  into 
separate  groups  for  each  Activity  Code  To  (ACT)  and  a  cover 
letter  is  prepared  to  accompany  each  group.  Each  group  of  SSR 
transactions,  technical  data  and  cover  letter  is  mailed  to  an 
IMM . 


(3)  The  Outgoing  SSR  List  is  kept  in  the  Data  Man¬ 
agement  Branch  as  a  manual  control,  suspense,  and  history  of  SSR 
transactions  submitted  by  PCC.  If  the  Data  Management  Branch  is 
contacted  by  the  end  item  cataloger  as  to  status  on  a  particular 
item  or  group  of  items,  this  SSR  List  is  checked  to  ensure  an 
SSR  transaction  was  submitted.  If  so,  the  IMM  is  contacted  via 
telephone  to  determine  status.  Followup  transactions  as  described 
by  the  IMM  Manual  are  not  used  by  TSARCOM. 

c.  Technical  Data  Tracking.  There  are  three  subevents 
within  this  major  event  shown  in  Figure  II-4. 

(1)  Outputs  from  the  automated  portion  of  this 
TSARCOM  unique  event  include  outgoing  SSR  transactions  and  Tech¬ 
nical  Data  Owed  Followup  Cards  (locally  termed  IOU  Cards).  These 
outputs  are  processed  by  the  Technical  Information  Division. 

(2)  The  Technical  Information  Division  checks  the 
technical  repository  for  the  technical  data  promised.  If  found, 
a  duplicate  aperture  card  is  made,  combined  with  the  SSR  trans¬ 
actions  and  mailed  to  the  IMM.  The  IOU  card  is  not  used  in  this 
case.  If  the  Technical  Data  promised  is  not  found,  the  SSR  trans¬ 
actions  and  the  IOU  card  are  filed  in  the  aperture  card  file 
where  the  Technical  Data  would  normally  appear.  When  the  required 
technical  data  arrives.  It  is  mailed  with  the  SSR  transactions 

to  the  IMM  and  the  IOU  card  is  destroyed.  If  notification  is 
received  from  the  contractor  that  the  required  technical  data 
will  not  be  provided  for  an  item,  a  statement  is  annotated  to 
that  effect  on  the  SSR  transactions  and  they  are  mailed  to  the 
IMM.  The  IOU  card  for  the  Item  is  destroyed. 

(3)  A  duplicate  item  name  transaction  containing  an 
action  code  in  cc  64  is  used  to  update  or  clear  the  automated 
suspense  in  the  TSARCOM  Technical  Data  Tracking  Application. 

5.  IMM  SSR  Processing  Phase.  This  processing  is  performed 
at  an  activity  other  than  the  provisioning  activity  and  is  not 
discussed  here. 


6.  SICC  SSR  Advice  Processing  Phase.  Figure  II-3  illus¬ 
trates  that  there  are  four  types  of  advice  transactions  that  may 
be  received  from  an  IMM.  Accept  advice  transactions  and  NSN 
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notifications  are  processed  similarly  and  are  discussed  together, 
followed  by  separate  discussions  for  offer  advice  transactions 
and  reject  advice  transactions. 


a.  Accept  Advice/NSN  Notification  Processing.  Processing 

of  these  advice  transactions  includes  the  three  major  events  shown 
in  Figure  11-3:  File  Maintenance,  Catalog  Data  Screening,  and 

Advice  Review. 

(1)  File  Maintenance.  The  two  subevents  shown  in 
Figure  II-4  are  included  in  this  major  event. 

(a)  Advice  transactions  from  an  I  MM  are  received 
by  TSARCOM  in  the  mail  or  over  AUTODIN.  If  advice  transactions 
are  received  via  AUTODIN,  the  Communications  Center  punches  the 
transactions  into  cards  and  forwards  them  to  the  Data  Management 
Branch.  Mailed  advice  transactions  have  the  Data  Management 
Branch  as  the  addressee. 

(b)  When  an  accept  advice  transaction  or  NSN 
Notification  is  received  by  the  Data  Management  Branch,  the  SSR 
transaction  list  is  pulled  from  the  suspense  file  and  the  Action 
Taken  Code  (ATC)  and/or  NSN  is  annotated  beside  the  appropriate 
item  on  the  list.  When  an  accept  advice  is  received  from  the 
IMM,  the  Data  Management  Branch  performs  catalog  data  screening. 

( 2 )  Catalog  Data  Screening 

(a)  Catalog  Data  Screening  is  performed  for 
each  item  for  which  accept  advice  is  received  to  ensure  proper 
user  recordation  has  been  accomplished  by  the  IMM  and  to  obtain 
the  assigned  NSN  for  SSR  transactions  submitted  with  part  num¬ 
bers  or  PSCNs.  This  screening  is  performed  against  both  the 
local  TIR  File  and  the  DIDSTIR  File. 

( 3 )  Advice  Review 

(a)  A  review  of  the  ATCs  returned  for  each  item 
is  performed  by  the  end  item  cataloger.  Accept  advice  including 
NSN  notification  is  noted  and  goes  into  the  manual  file  kept  by 
the  end  item  cataloger.  This  allows  tracking  of  support  on 
items  required  before  fielding  of  the  end  item. 

b.  Reject  Advice  Processing.  Two  of  the  major  events 

shown  under  the  SICC  SSR  Advice  Processing  Phase  in  Figure  II-3 
are  included  in  reject  advice  processing:  File  Maintenance  and 

Advice  Review. 

(1)  File  Maintenance.  There  are  two  subevents 
included  in  this  major  event  as  shown  in  Figure  II-4. 
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(a)  Reject  advice  transactions  may  be  received 
h  v  mail  or  A  L'  TO  DIN  and  arrive  in  the  Data  Management  Branch  as 
If s  r I  bed  above. 


(b)  Items  for  which  reject  advice  is  received 
tre  listed  along  with  the  ATC  on  a  Reject  Ledger.  The  I  MM  may 
submit  a  specitlc  reject  reason  on  a  form  or  separate  sheet. 

When  the  reject  transaction  is  mailed  by  the  I  MM ,  this  form  ac¬ 
companies  the  transaction;  when  the  reject  transaction  is  trans¬ 
mitted  over  A  U  T  0  D  l  N  ,  the  form  is  rec*ived  later  by  mail  and 
matched  t o  the  original  SSR  and  reject  transactions  by  P CC ,  ISN, 
DOR,  and  activity  codes.  The  1MM  is  also  required  to  return  the 
technical  data  submitted  for  any  SSR  transaction  rejected.  This 
technical  data  is  retained  by  the  Data  Management  Branch  for  re¬ 
submittal  with  the  corrected  SSR  transactions.  The  reject  advice 
transactions  and  other  pertinent  information  is  forwarded  to  the 
end  item  cataloger  for  review. 

(2)  Advice  Review.  There  are  two  subevents  included 
Included  in  this  major  event. 

(a)  Reject  advices  are  reviewed  to  determine 
the  error.  When  the  data  in  error  has  been  identified,  the  end 
item  cataloger  contacts  the  appropriate  organizational  element 
for  correct  data  and  forwards  this  data  to  the  Data  Management 
Branch  . 


(b)  Corrected  data  for  rejected  SSR  transac¬ 
tions  is  combined  with  original  SSR  data  in  the  Data  Management 
Branch  and  new  SSR  transactions  are  manually  formatted  and  key¬ 
punched.  These  new  SSR  transactions  are  combined  with  appropriate 
technical  data  and  mailed  to  the  I  MM  as  re s u bm i 1 1 a  1 s  . 

c.  Offer  Advice  Processing.  The  only  major  event  in¬ 
cluded  in  processing  offer  advices  is  advice  review  and  there 
are  five  subevents  within  this  major  event. 

(1)  Advice Review 


(a)  Offer  advice  transactions  may  be  received 
by  mail  or  AUTODIN  and  arrive  in  the  Data  Management  Branch  as 
described  above.  The  I  MM  Manual  requires  the  I  MM  to  provide  the 
SICC  with  technical  data  for  offered  items  when  necessary.  This 
technical  data  is  mailed  with  the  offer  advice  transaction  or 
mailed  separately  and  matched  up  by  the  SICC  using  PCC,  ISN, 

DOR,  and  activity  codes.  These  advices  and  the  technical  aata 
are  forwarded  to  the  end  item  cataloger. 

(b)  The  end  item  cataloger  reviews  the  offer 
advices  and  forwards  the  offer  advices  and  associated  technical 
data  to  the  DM  for  review  and  accept/re ject  decision. 
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(c)  Offer  advices  received  by  the  DM  are  re¬ 
ceived  In  conjunction  with  the  original  item  requested.  Based 

on  this  review  a  decision  is  made  to  accept  or  reject  the  offered 
item.  The  accept  or  reject  decision  goes  to  the  end  item  cata- 
1 o ge  r  . 

(d)  Accept  decisions  are  noted  in  the  file  the 
same  as  a  accept  advice  and  action  is  initiated  to  update  the 
local  TIR  File  and  PMR  File  to  reflect  the  offered  item  through 
the  provisioning  subsystem.  All  decisions  are  forwarded  to  the 
Data  Management  Branch. 

(e)  Offer  reply  transactions  are  formatted  and 
keypunched  in  the  Data  Management  Branch.  A  cover  letter  is 
prepared  and  the  transactions  are  mailed  to  the  appropriate  I  MM . 

E.  SICC  NONPROVISIONING  SSR  GENERATION  AND  PROCESSING 


The  Army  Outgoing  Non p r o v i s i on i n g  SSR  Operational  System  is 
depicted  in  Figure  II-5.  The  organizational  relationships  are 
similar  to  those  already  discussed  for  the  operational  provi¬ 
sioning  system.  The  major  difference  between  the  provisioning 
and  no n p r o v i s i o n i ng  systems  is  the  origination  of  SSR  candidates 
and  the  partial  automation  of  provisioning  processing  vs  totally 
manual  no n p r o v i s i on i ng  processing. 

The  major  source  of  nonprovisioning  SSR  items  are  item  re¬ 
quests  which  originate  at  field  activities.  These  are  items 
that  were  determined  co  be  nonsupport  items  during  the  provision¬ 
ing  of  the  end  item,  or  items  in  equipments  that  were  not  provi¬ 
sioned.  The  item  requests  are  mailed  to  the  MRC  responsible  for 
managing  the  end  item.  The  end  item  cataloger  receives  these 
requests  and  the  nonprovisioning  processing  phase  begins.  The 
Army  Outgoing  Nonprovisioning  SSR  Work  Flow  Chart  (Figure  II-6) 
is  used  in  discussing  each  processing  phase  shown  In  Figure  II-5. 

1.  Non pr o v 1 s i on i ng  Processing  Phase.  This  processing  phase 
consists  of  four  major  events  as  shown  in  Figure  I  I  —  5  .  Catalog 
Data  Screening,  IMC  ,  File  Maintenance,  and  Requirements  Deter¬ 
mination. 

a.  Catalog  Data  Screening.  Figure  II-6  illustrates  the 
six  subevents  included  in  this  major  event. 

(1)  Each  item  request  received  is  reviewed  by  the 
end  item  cataloger.  As  part  of  this  review,  catalog  data  screen¬ 
ing  is  performed. 

(2)  A  local  TIR  inquiry  is  formatted,  keypunched 
and  forwarded  to  CMD  for  input  to  CCSS. 


Figure  XI- 


Figure  II 


(3)  Input  to  the  CCSS  local  TIR  Inquiry  application 
by  the  Computer  Management  Division. 

(A)  Output  from  the  local  inquiry  is  forwarded  to 
the  end  item  cataloger.  This  output  is  reviewed  and  if  a  nega¬ 
tive  response  is  received,  a  DLSC  screening  transaction  is  gener¬ 
ated  by  the  end  item  cataloger  and  forwarded  to  the  Communications 
Center  . 


(5)  The  screening  transaction  is  processed  against 
the  DIDSTIR  File  at  DLSC  and  results  are  returned  to  the  MRC 
Communications  Center  who  forwards  them  to  the  end  item  cata¬ 
loger  . 


(6)  The  end  item  cataloger  reviews  the  screening 
results,  both  local  and  DLSC,  and  assigns  the  FSC  for  new  items. 
All  items  are  then  given  to  the  cognizant  FSC  cataloger  for 
determination  of  additional  cataloging  data. 

b.  IMC .  This  major  event  consists  of  two  subevents  as 
shown  in  Figure  II-6. 

(1)  Each  item  is  reviewed  by  the  FSC  cataloger  and 
an  IMC  and  a  Management  Control  Number  (MCN)  is  assigned  for  new 
items  . 

(2)  When  an  item  is  managed  or  is  to  be  managed  by 
another  activity  and  an  Army  activity  is  recorded  as  a  user  of 
the  item,  an  SSR  transaction  may  or  may  not  be  sent  to  the  IMM 
depending  on  the  Army  SICC.  Items  to  be  managed  locally,  or 
items  in  which  SSRs  are  to  be  sent,  are  forwarded  to  the  appro¬ 
priate  item  manager.  Skeleton  SSR  transactions  are  coded  by  the 
FSC  cataloger  before  forwarding  these  items  for  the  item  nanager. 

c.  File  Maintenance.  A  single  subevent  is  included  in 
this  major  event. 

(1)  The  FSC  cataloger  initiates  action  at  this 
point  to  update  the  local  TIR  File  by  generating  update  transac¬ 
tions  for  items  already  on  the  file  (as  determined  from  catalog 
data  screening)  and  generating  transactions  to  establish  new 
items  on  the  file.  These  transactions  are  input  to  CCSS  by  the 
Computer  Management  Division. 

d.  Requirements  Determination.  The  two  subevents  in¬ 
cluded  in  this  major  event  are  shown  in  Figure  II-6. 

(1)  The  inventory  manager  reviews  each  item  and 
Initiates  a  buy  for  locally  managed  items  when  required.  SSR 
items  have  the  replenishment  and  retail  quantities  computed  by 
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the  Inventory  manager  in  addition  to  completing  inventory  man¬ 
agement  data  on  the  skeleton  SSR  transactions  forwarded  to  him. 
Upon  completing  the  coding  of  the  SSR  transactions,  they  are 
returned  to  the  end  item  cataloger. 

(2)  As  with  provisioning  items,  the  end  item  cata¬ 
loger  reviews  data  returned  to  him  by  the  FSC  cataloger  and  item 
manager  for  completeness  only  -  not  validity  or  accuracy.  The 
coded  SSR  transactions  and  any  technical  data  is  forwarded  to 
the  Data  Management  Branch. 

2.  S1CC  SSR  Processing  Phase.  This  processing  phase  con¬ 
sists  of  a  single  major  event  (File  Maintenance)  as  shown  in 
Figure  I  I  —  5 . 

a.  File  Maintenance.  This  major  event  consists  of  the 
three  subevents  shown  in  Figure  II-6. 

(1)  In  the  Data  Management  Branch  each  item  is  re¬ 
viewed  for  completeness  and  accuracy.  The  PCC,  1SN  and  DOR  is 
assigned  to,  and  coded  for,  each  SSR  transaction.  The  coded 
transactions  are  forwarded  to  DMIS  for  keypunching  and  returned 
to  the  Data  Management  Branch  for  mailing. 

(2)  Just  prior  to  mailing,  a  control  file  of  3x5 
cards  is  established. 

(3)  SSR  cards  are  mailed  with  a  cover  letter  to  the 
appropriate  IMM. 

3.  IMM  SSR  Processing  Phase.  As  with  Provisioning  SSR 
transactions,  this  processing  phase  is  performed  outside  the  SICC 
activity  and  thus,  is  not  discussed  here. 

A.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
consists  of  four  major  events  as  shown  in  Figure  I  I  —  5 :  File 

Maintenance,  Catalog  Data  Screening,  Advice  Review  and  Notifica¬ 
tion  Action.  Processing  in  this  phase,  for  the  first  three  major 
events,  is  identical  to  that  discussed  for  Provisioning  Outgoing 
SSR  Generation  and  Processing  above.  Therefore,  only  the  major 
event  Notification  Action  is  discussed  here  and  is  shown  in 
Figure  I  I  -  6  • 


a .  Notification  Action .  When  the  End  Item  Cataloger 
receives  accept  advice  from  the  IMM,  or  receives  an  accept  deci¬ 
sion  from  the  DM  for  an  item,  he  prepares  a  notification  to  the 
field  activity  or  maintenance  activity  where  the  item  request 
originated.  This  notification  is  forwarded  by  mail  and  gives 
the  originator,  the  manager  of  the  item,  the  NSN  and  any  other 
data  required  to  obtain  the  item  through  normal  supply  channels. 
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ARMY  INCOMING  SSR  PROCESSING 


The  processing  of  Incoming  SSRs  at  TSARCOM  is  illustrated  by 
the  Army  Incoming  SSR  Operational  System  is  Figure  II-7.  Pro¬ 
cessing  in  this  operational  system  is  on  a  PCC  package  basis; 
that  is,  all  SSR  transactions  received  together  at  TSARCOM  are 
processed  together  including  advice  transaction  preparation  and 
mailing  of  the  advice  transaction  to  the  SICC.  The  Army  Incoming 
SSR  Work  Flow  Chart  in  Figure  II-8  illustrates  the  processing 
flow  of  SSR  transactions  in  this  operational  system  and  shows 
the  relationships  between  major  events,  subevents  and  the  orga¬ 
nizational  elements  performing  these  subevents. 

Provisioning  SSR  items  and  Non p r o v i s i on i n g  SSR  items  are  pro¬ 
cessed  in  largely  the  same  manner,  and  so,  are  discussed  together 
with  differences  pointed  out  where  they  exist.  Resubmissions  by 
the  SICC  are  treated  as  initial  submissions.  Change  submissions 
by  the  SICC  are  rarely  received  by  TSARCOM  and  there  are  no  spe¬ 
cific  procedures  for  processing  them. 

1.  SICC  SSR  Processing  Phase.  This  processing  phase  takes 
place  at  an  activity  other  than  TSARCOM  and  is  where  SSR  trans¬ 
actions  and  followup  transactions  to  be  processed  at  TSARCOM 
originate  . 

2.  WIMM  SSR  Processing  Phase.  This  processing  phase  con¬ 
sists  of  the  seven  major  events  shown  in  Figure  11-7:  Edit/ 

Validation,  Catalog  Data  Screening,  Advice  Decision,  File  Mainte¬ 
nance,  Catalog  Actions,  Requirements  Determination  and  Advice 
Decision  . 

a.  Edit/Valldatlon.  This  major  event  is  made  up  of  two 
subevents  as  shown  in  Figure  II-8. 

(1)  Incoming  SSR  transactions  are  received  In  the 
Data  Management  Branch  where  they  are  first  entered  into  a  log. 
This  log  serves  as  a  record  of  those  SSR  transactions  received 
by  TSARCOM. 


(2)  A  manual  validation  is  next  performed  which 
generally  is  a  cursory  scan  of  each  SSR  for  proper  control  in¬ 
formation  and  valid  retail  and  replenishment  quantities.  Any 
discrepancies  found  are  handled  by  a  telephone  call  to  the  sub¬ 
mitting  SICC  for  the  correct  information  and  manual  correction 
by  TSARCOM. 

b.  Catalog  Data  Screening.  The  eight  subevents  included 
in  this  major  event. 
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(1)  The  SSR  transactions  received  are  then  divided 
into  two  groups.  One  group  consists  of  SSR  transactions  contain¬ 
ing  items  for  which  an  NSN  is  already  assigned.  The  second  group 
consists  of  SSR  transactions  containing  items  for  which  no  NSN 
has  been  assigned.  Processing  on  this  second  group  is  suspended, 
while  the  first  group  is  screened  for  cataloging  data. 


(2)  A  request  for  a  local  TIR  file  printout  is  pre¬ 
pared  for  all  SSR  transactions  containing  NSN  items.  This  request 
is  processed  by  the  Computer  Management  Division. 


(3)  From  the  requests  received  from  the  Data  Manage¬ 
ment  Branch,  the  Computer  Management  Division  formats  and  key¬ 
punches  input  transactions  to  be  processed  by  CCSS.  The  requests 
are  then  processed  automatically,  producing  printouts  for  those 
items  on  the  file,  and  a  No  Match  List  for  those  items  not  found 
on  the  local  TIR  File.  These  results  are  returned  to  the  Data 
Management  Branch. 

(4)  The  local  TIR  File  printouts  are  reviewed  in 
the  Data  Management  Branch.  Those  NSN  items  appearing  on  the  No 
Match  List  are  screened  against  the  DIDSTIR  File. 

(5)  DLSC  screening  transactions  are  formatted  and 
keypunched  before  forwarding  to  the  Computer  Management  Division. 

(6)  The  DLSC  screening  transactions  are  entered 
into  CCSS  by  the  Computer  Management  Division.  CCSS  sets  up  an 
automated  suspense  on  these  transactions  and  prepares  them  for 
AUTODIN  transmittal.  The  AUTODIN  transactions  on  magnetic  tape 
go  to  the  Communications  Center  for  transmittal  to  DLSC. 


(7)  The  transactions  are  screened  against  the 
DIDSTIR  File  with  results  returned  through  the  MRC  Communica¬ 
tions  Center  to  the  Computer  Management  Division  for  input  to 
the  CCSS. 


(8)  The  automated  suspense  on  the  screening  trans¬ 
actions  is  cleared  and  results  are  printed  for  functional  use. 
The  hard  copy  DLSC  screening  results  are  forwarded  to  the  Data 
Management  Branch. 

c.  Advice  Decision.  This  major  event  consists  of  the 
three  subevents  shown  in  Figure  II-8.  The  advice  decision  takes 
place  in  the  Data  Management  Branch  as  shown  by  this  figure. 

(1)  After  all  screening  results  have  been  received, 
the  Data  Management  Branch  gathers  all  available  information  on 
each  item  requested  in  the  SSR  transaction  package  received. 


(a)  If  an  SSR  transaction  is  for  an  item  with 
an  NSN  and  the  item  is  actively  managed  by  the  MRC,  an  accept 
advice  is  assigned  the  item.  For  non p r o v i s ioni ng  SSR  transac¬ 
tions,  this  accept  advice  is  always  ATC  'YD'  (accept  support, 
procure  upon  demand). 

(b)  When  an  SSR  transaction  contains  an  NSN 
and  the  catalog  data  screening  indicates  a  substitute  item,  an 
offer  advice  for  the  substitute  item  is  assigned.  When  the  offer 
is  rejected  by  the  SICC  and  the  original  item  is  actively  managed 
by  TSARCOM,  support  is  accepted  for  the  original  item;  otherwise 
support  is  rejected. 

(c)  When  an  SSR  transaction  contains  an  NSN 
not  actively  managed  by  TSARCOM,  the  SSR  is  assigned  a  reject 
advice.  If  an  SSR  transaction  is  for  an  item  without  an  NSN,  it 
is  generally  assigned  reject  advice  routinely. 

(2)  When  advice  decisions  have  been  made  for  all 
items  in  the  SSR  package,  advice  cards  are  formatted  for  each 
item.  The  cards  are  keypunched  by  the  ADP  Input  Branch.  The 
Data  Management  Branch  prepares  a  cover  letter  and  mails  the 
advice  cards  to  the  SICC. 

(3)  Notifications  are  prepared  for  items  accepted 
for  support  and  offered  items  accepted  by  the  SICC  to  the  FSC 
cataloger,  the  item  manager,  and  the  DM.  The  item  manager  does 
not  receive  a  notification  when  both  the  retail  and  replenish¬ 
ment  quantities  in  the  LISSR  transaction  are  zero.  The  notifi¬ 
cations  consist  of  a  copy  of  the  original  SSR  transactions  and  a 
form  containing  other  item  information;  e.g.,  the  ATC  assigned. 

d.  File  Maintenance.  This  major  event  consists  of  three 
8  u  be  ven  t  s  . 

(1)  The  original  SSR  transactions,  correspondence 
and  screening  results  are  retained  in  manual  history  files. 

(2)  If  a  followup  transaction  is  received  from  the 
SICC,  the  history  files  are  checked  to  determine  the  response 

to  be  given  to  the  SICC.  The  response  takes  the  form  of  a  letter 
mailed  to  the  SICC  or  a  telephone  call  to  the  SICC  providing  him 
with  the  requested  status. 

(3)  The  Directorate  for  Maintenance  reviews  each 
item  for  which  a  notification  is  received  and  prepares  an  update 
transaction  to  add  the  End  Article  Application  to  the  local  TIR 
File.  These  transactions  are  forwarded  to  DMIS  who  keypunches 
the  transactions  and  inputs  them  to  CCSS  where  the  local  TIR  Is 
updated . 
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e.  Catalog  Actions.  This  major  event  is  made  up  of  a 
single  subevent. 

(1)  The  FSC  cataloger  examines  each  notification 
for  proper  cataloging  data.  If  the  SICC  activity  is  not  already 
registered  as  a  user,  an  add  user  transaction  is  formatted  and 
keypunched  to  update  the  DIDSTIR  file  and  local  TIR  files.  Each 
transaction  is  forwarded  to  the  Computer  Management  Division  for 
input  to  CCSS  where  it  will  be  forwarded  via  AUTODIN  to  DLSC  by 
the  Communications  Center.  When  DLSC  updates  the  DIDSTIR  file, 
notifications  are  automatically  generated  to  all  users  and  for¬ 
warded  via  AUTODIN  so  that  local  files  may  be  updated.  When  this 
notification  is  received  by  the  MRC,  CCSS  automatically  processes 
the  transaction  and  updates  the  local  TIR  File. 

f.  Requirements  Determination.  This  major  event  con¬ 
sists  of  two  subevents  performed  by  the  item  manager. 

(1)  The  item  manager  receives  the  item  notifications 
from  the  Data  Management  Branch  and  reviews  each  item  for  retail 
and  replenishment  requirements  and  the  advice  given  to  the  SICC. 

(2)  The  item  manager,  based  on  his  review,  will  take 
action  to  adjust  stock  levels  and  initiate  buys  when  necessary. 

g.  Advice  Decision.  This  major  event  consists  of  two 
subevents  and  may  result  in  a  revision  of  the  advice  already 
forwarded  to  the  SICC. 

(1)  Based  upon  his  review,  the  item  manager  may 
disagree  with  the  advice  returned  to  the  SICC  by  the  Data  Manage¬ 
ment  Branch.  When  this  occurs  a  Disposition  Form  is  prepared  Lo 
the  Data  Management  Branch  revising  the  accept  advice  given  to 
the  SICC. 


(2)  The  Data  Management  Branch  will  prepare  and 
mail  a  new  advice  transaction  for  each  of  these  items. 

3 .  SICC  SSR  Advice  Processing  Phase .  This  processing  takes 
place  at  an  activity  other  than  TSARCOM  and  is  not  discussed  in 
detail.  Generally,  this  processing  involves  advice  transactions 
from  TSARCOM  to  these  activities  and  may  result  in  SSR  resubmit¬ 
tals  and/or  offer  replies  as  shown  in  Figure  1 1  —  7 . 

G.  CIMM  ORGANIZATIONAL  STRUCTURE 


The  organizational  elements  performing  CIMM  SSR  processing 
by  the  Army  are  depicted  in  Figure  II-9.  This  figure  shows  there 
are  five  directorate  level  organizations  within  TARCOM  performing 
CIMM  SSR  related  processing  actions.  These  are  the  Directorate 
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for  Materiel  Management,  the  Directorate  for  Management  Informa¬ 
tion  Systems,  the  Directorate  for  Maintenance,  the  Directorate 
for  Procurement  and  Production  and  the  Directorate  for 
Engineering . 

1 •  Directorate  for  Materiel  Management  (DMM) .  There  are 
two  division  level  organizations  performing  incoming  CIMM  SSR 
related  processing  actions.  These  are  the  Cataloging  Division 
and  the  Special  Vehicle  Division. 

a.  Cataloging  Division.  There  are  two  branches  within 
the  Cataloging  Division  performing  SSR  processing  actions. 

(1)  The  Control  Branch  in  this  division  serves  as  a 
central  focal  point  for  communication  between  the  cataloging 
division  and  other  organizational  elements  within  and  outside  of 
the  MRC.  This  branch  provides  administrative  functions  for  the 
division  in  controlling  receipt,  distribution,  quality  control 
and  input  of  cataloging  products  and  mail. 

(2)  The  Tactical  Vehicle  Branch  within  this  divi¬ 
sion  provides  cataloging  support  for  all  assigned  DoD  Mission 
Classes  regardless  of  application  or  user  interest.  Catalogers 
in  this  branch  assign  Item  Management  Codes  (IMC)  and  Federal 
Supply  Codes  (FSC)  for  all  new  items  entering  the  Army  system. 
This  branch  also  analyzes  and  resolves  conflicts  in  nomenclature, 
FSC  classifications,  stock  numbers,  part  numbers  and  management 
data  in  Army  and  DoD  files;  and  performs  necessary  operations  to 
obtain  logistics  data  for  incoming  SSRs. 

b .  Special  Vehicle  Division.  The  Special  Vehicle  Divi¬ 
sion  within  this  Directorate  has  the  mission  of  directing  and 
controlling  execution  of  the  integrated  materiel  management  func¬ 
tions  for  assigned  end  items  as  well  as  the  DoD  mission  classes 
of  tires,  tubes  and  repair  parts. 

(1)  The  Tire  Management  Branch  within  this  division 
performs  the  SSR  related  functions  of  support/nonsupport  deter¬ 
minations,  support  date  determinations,  inclusion  oi  SSR  quan¬ 
tities  in  requirements  computations  and  forecasting,  AAC  deter¬ 
minations  ana  budgeting  for  repetitive  SSR  requirements.  This 
branch  consists  of  item  managers  and  performs  integrated  materiel 
management  functions  for  the  assigned  DoD  mission  classes. 

2.  Directorate  for  Management  Information  Systems  (DMIS) . 

The  Computer  Operations  Branch  within  the  Computer  Management 
Division  of  this  Directorate  performs  several  SSR  processing 

ons.  All  inputs  to  establish  items  on  the  PMR  and  local  TIR 
•  or  update  Items  on  these  files  are  input  to  the  CCSS  by 
tin  i  branch.  Also  automated  processing  of  communications  between 
TARO.OM  and  DISC  begins  in  this  branch.  This  branch  performs  key¬ 
punching  of  SSR  advice  transactions  to  be  forwarded  to  the  SICC. 
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3.  Directorate  for  Maintenance  (DM).  One  office  In  this 

Directorate  is  involved  in  CIMM  SSR  processing:  the  Initial 

Materiel  Suppo r t / Pr o vi s io n i ng  Office.  This  office  manages  the 
provisioning  support  program  and  maintains  the  PMR  File.  It 
also  provides  necessary  documentation  for  additions  and  changes 
to  support  items  on  the  PMR  File  and  Local  TIR  File. 

4.  Directorate  for  Procurement  and  Production  (DPP).  The 
only  action  performed  in  this  directorate  related  to  CIMM  SSR 
processing  is  in  processing  procurement  actions  initiated  by 
item  managers  in  the  Tire  Management  Branch. 

5.  Directorate  for  Engineering  (DE).  The  Secondary  Item 
Engineering  Branch  in  the  Technical  Data  Division  within  this 
Directorate  prepares  engineering  data  required  to  support  pro¬ 
curement  of  spare  parts;  coordinates  the  evaluation  of  vendor 
items  for  competitive  procurement;  maintains  technical  data  on 
competitively  procured  items;  and  assembles  and  approves  all 
secondary  item  procurement  technical  data  packages. 

H.  INTRODUCTION  TO  ARMY  INCOMING  CIMM  SSR  PROCESSING 


The  processing  of  incoming  SSRs  on  a  CIMM  basis  at  TARCOM  is 
significantly  different  from  those  processed  on  a  WIMM  basis  at 
TSARCOM.  The  differences  in  organizational  alignments  between 
these  MRCs  is  readily  evident  from  comparison  of  their  respec¬ 
tive  Organizational  Structures  (Figure  II-2  and  II-9).  The  pro¬ 
cessing  differences  in  active  NSN  submissions  betwen  these  MRCs 
are  minute;  however,  while  TSARCOM  as  a  WIMM  routinely  rejects 
SSRs  for  items  not  actively  managed  by  the  Command,  TARCOM,  as 
DoD  Mission  assignee,  is  required  to  process  SSRs  for  inactive 
NSNs ,  PSCNs  and  part  numbers  as  a  CIMM.  The  processing  at  TARCOM 
of  active  NSNs  vs  inactive  NSNs/PSCNs  vs  part  numbers  differs 
significantly  and  therefore  each  is  discussed  separately  with 
individual  work  flow  charts  developed  for  each. 

The  Army  Incoming  CIMM  SSR  Operational  System  illustrated  in 
Figure  11-10  represents  the  operational  system  at  TARCOM  under 
which  each  of  the  above  three  categories  are  processed.  The 
dashed  lines  around  some  of  the  major  events  in  this  figure  in¬ 
dicate  these  events  may  not  occur  for  all  three  categories  or 
may  not  occur  in  the  order  shown.  There  is  no  distinction  be¬ 
tween  provisioning  and  nonprovisioning  SSR  processing  in  this 
operational  system  and  there  are  no  processing  priorities.  LISSR 
change  submissions  are  handled  on  a  case  by  case  basis  with  no 
established  procedures  available. 

I.  INCOMING  CIMM  ACTIVE  NSN  SSR  PROCESSING 


The 
NSN  SSR 


phases  and  major  events  included  in  incoming  CIMM  active 
processing  are  shown  in  Figure  11-10.  The  active  NSN 
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NCOMING  ClMM  SSR  OPERATIONAL  SYSTEM 


work  flow  is  shown  In  Figure  11-11  and  breaks  the  phases  and 
major  events  down  into  subevents  and  organizational  elements  per¬ 
forming  the  subevents. 

1.  SICC  SSR  Processing  Phase.  This  processing  phase  occurs 
at  SICC  activities  where  SSRs  to  be  processed  by  TARCOM  originate. 

2.  CIMM  SSR  Processing  Phase.  This  processing  phase  con¬ 
sists  of  eight  major  events  for  processing  active  NSN  SSRs.  These 
major  events  are  shown  in  Figure  11-10  and  include  Ed  it /Val idat ion  , 
Catalog  Data  Screening,  Advice  Decision,  File  Maintenance,  Re¬ 
quirements  Determination,  Advice  Decision,  Catalog  Actions  and 
File  Maintenance.  Processing  through  the  first  three  major  events 
generally  occurs  on  a  PCC  package  basis  while  processing  in  the 
remainder  is  done  on  an  item  (LISSR  package)  basis. 

a.  Edit/Validation .  There  are  four  subevents  included 
in  this  major  event. 

(1)  Incoming  SSR  transactions  from  SICCs  are  re¬ 
ceived  in  the  Control  Branch.  Each  SSR  package. is  scanned  to 
locate  the  PCC/ACF  combination  in  the  package.  This  PCC/ACF 
combination  is  checked  against  a  control  register  to  determine 
if  it  has  been  received  previously  and,  if  so,  to  which  cata- 
loger  the  package  was  assigned.  When  the  PCC/ACF  combination 
cannot  be  located  on  the  register,  the  SSR  package  is  assigned 
to  a  cataloger,  based  on  end  item  name  or  FSC,  and  a  transaction 
is  prepared  to  add  the  combination  to  the  register.  Each  SSR 
package  is  hand-carried  to  the  supervisory  cataloger. 

(2)  The  supervisory  cataloger  records  receipt  of 
each  SSR  package  in  a  branch  log  and  then  gives  it  to  the 
assigned  cataloger  for  processing. 

(3)  Upon  receipt  of  each  SSR  package,  the  cataloger 
establishes  an  informal  con t r ol / sus pe ns e . 

(4)  The  validation  performed  by  the  cataloger  is 
cursory  and  keyed  to  a  few  specific  data  elements.  PDSSR  trans¬ 
action  data  elements  validated  include  DIC,  End  Item  Application 
and  Number  of  SSRs  enclosed.  LISSR  transactions  are  validated 
for  proper  DIC  and  numeric  quantities.  Other  SSR  transactions 
are  simply  checked  for  proper  DIC.  Errors  detected  are  either 
immediately  corrected  by  the  cataloger  or  corrected  after  con¬ 
tacting  the  SICC  via  telephone  to  obtain  the  proper  entry  for 
each  data  element  in  error.  This  validation  process  eliminates 
return  of  SSR  packages  to  a  SICC  because  of  validation  errors. 

b.  Catalog  Data  Screening.  This  major  event  consists 
of  six  subevents  and  includes  screening  against  locally  main¬ 
tained  files  and  DLSC  files. 


Transmittal  to  DLSC 


Figure  11-11 


(1)  After  validation,  each  SSR  package  is  broken 
down  by  line  item  for  further  processing.  A  transaction  to 
screen  each  item  against  the  local  TIR  File  is  prepared.  These 
inquiry  transactions  are  input  to  the  next  CCSS  processing  cycle. 


(2)  Batched  inquiries  from  the  Cataloging  Branch  are 
input  to  the  next  processing  cycle  of  CCSS  by  DMIS.  Hard  copy 
results  from  this  screening  are  returned  to  the  requesting  cata- 
loger  through  th^  Control  Branch. 

(3)  When  the  screening  result  for  an  item  is  nega¬ 
tive  (no  match),  the  cataloger  manually  screens  the  item  against 
available  manual  files;  e.g.,  Master  Cross  Reference  List  (MCRL) . 

(4)  Items  not  located  by  either  of  the  above  screen¬ 
ing  actions  are  screened  against  DLSC  files.  A  DLSC  screening 
transaction  is  prepared  in  the  LTI  format. 

(5)  These  screening  transactions  are  input  to  the 
next  CCSS  processing  cycle  by  DMIS.  CCSS  produces  a  magnetic 
tape  containing  these  transactions  which  are  transmitted  to  DLSC 
via  AUTODIN. 


(6)  Hard  copy  results  from  DLSC  are  produced  by  CCSS 
and  forwarded  to  the  requesting  cataloger  through  the  Control 
Branch . 


c.  Advice  Decision.  This  major  event  consists  of  three 
subevents  resulting  in  reject  advices  as  shown  in  Figure  1 1  —  1 1 . 

(1)  The  cataloger  reviews  the  screening  results 
received  for  each  item.  When  the  screening  results  indicate  the 
item  is  managed  by  another  IMM,  or  a  no  match  condition  exists 
for  all  screening  actions,  indicating  submission  of  an  invalid 
NSN,  the  cataloger  will  reject  the  SSR  transaction. 

(2)  Reject  advice  transactions  containing  ATC  '36' 
(other)  are  formatted  for  these  items  and  forwarded  to  DMIS  for 
keypunching . 

(3)  The  cataloger  prepares  necessary  documentation 
to  accompany  each  reject  advice  transaction  and  mails  each  to 
the  appropriate  submitter. 

d.  File  Maintenance.  This  major  event  consists  of  a 
single  subevent  to  establish  a  history  record  of  items  on  which 
an  advice  decision  has  been  reached  and  forwarded  to  the  SSR 
submitter. 


268 


(1)  The  cataloger  at  this  point  clears  the  informal 
suspense  for  rejected  items  and  transfers  the  SSR  transactions 
received  for  these  items  to  a  manual  card  history  file  for  a  two 
year  retention.  This  history  file  is  sequenced  on  PCC,  DOR,  ISN 
and  ACF. 


e.  Requirements  Determination.  This  major  event  con¬ 
sists  of  two  subevents  and  is  performed  by  the  item  manager. 

(1)  Items  on  which  reject  advice  transactions  were 
not  prepared  are  forwarded  to  the  item  manager.  These  are  items 
which  have  been  determined  to  be  actively  managed  by  TARCOM,  and 
thus,  accept  advice  will  be  returned  to  the  SICC;  however,  the 
ATC  to  be  returned  is  assigned  by  the  item  manager.  The  cataloger 
starts  the  I MM  processing  time  established  by  the  I  MM  Manual  upon 
transfer  of  items  to  the  item  manager. 

(2)  The  item  manager  locates  the  manual  records  kept 
for  each  item  to  see  if  screening  results  are  present.  If  not, 

a  local  TIR  inquiry  will  be  generated  and  processed  as  described 
above.  When  the  item  manager  has  collected  the  manual  records 
and  screening  results  for  each  item,  he  pulls  the  current  AAC 
from  his  records.  The  replenishment  quantity  and  Date  Repair 
Parts  Required  (DRPR)  from  the  SSR  transaction  is  checked  against 
the  production  leadtime  and  asset  status  of  the  item  managers' 
records  . 


f.  Advice  Decision.  This  major  event  is  made  up  of 
three  subevents.  This  is  an  accept  advice  decision  made  by  the 
item  manager. 

(1)  The  current  AAC  is  used  to  determine  the  ATC  to 
be  returned  to  the  SICC  and  the  other  data  is  used  to  determine 
if  SSR  requirements  can  be  supported  by  the  DRPR;  if  not,  an 
alternate  support  date  is  determined.  Both  the  ATC  and  alter¬ 
nate  support  date  are  annotated  on  each  SSR  transaction  which  is 
then  returned  to  the  cataloger. 

(2)  When  the  cataloger  forwards  items  to  the  item 
manager  for  processing,  an  informal  suspense  of  10  days  is  estab¬ 
lished.  If  the  cataloger  notices  that  item  manager  action  is 
overdue,  he  may  followup  by  telephone  or  memo  requesting  status. 
Items  returned  to  the  cataloger  have  this  suspense  cleared  and 
accept  advice  transactions  formatted.  These  transactions  are 
sent  to  DMIS  for  keypunching. 

(3)  The  cataloger  prepares  a  cover  letter  and  mails 
the  transactions  to  the  SICC. 

g.  Catalog  Actions .  This  jajor  event  consists  of  three 
subevents  to  perform  all  user  type  actions. 
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(1)  After  formatting  the  advice  transactions,  the 
cataloger  determines  if  any  cataloging  actions  are  necessary, 
such  as  adding  the  SICC  as  a  user  activity.  He  then  formats 
these  cataloging  transactions  and  forwards  them  to  the  Control 
Branch. 


(2)  The  catalog  update  transactions  undergo  quality 
review  by  the  Control  Branch  before  they  are  input  to  CCSS. 

(3)  The  batched  catalog  update  transactions  are  in¬ 
put  to  the  next  cycle  of  CCSS  for  update  of  DLSC  files  and  the 
local  TIR  File. 

h.  File  Maintenance.  This  major  event  consists  of  a 
single  subevent  to  provide  a  history  record  of  SSR  transactions 
processed. 


(1)  When  the  advice  transactions  have  been  mailed 
to  the  SICC,  the  SSR  transactions  are  filed  in  the  same  history 
file  the  rejected  SSR  transactions  were  filed  earlier.  Any  hard 
copy  documentation  is  kept  in  a  separate  history  file  in  file 
folders . 

3.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
occurs  at  SICC  activities  and  provides  for  processing  of  advice 
transactions  generated  by  TARCOM.  If  the  SICC  does  not  receive 
an  advice  transaction  within  35  days  of  SSR  transaction  submit¬ 
tal,  he  may  generate  a  followup  transaction  and  either  mail  it 
or  transmit  it  via  AUTODIN  to  TARCOM. 

4.  CIMM  Followup/Offer  Reply  Processing  Phase.  This  pro¬ 
cessing  phase  completes  the  cycle  of  SSR  processing.  For  active 
NSNs  this  phase  consists  only  of  file  maintenance  actions  to 
respond  to  followup  transactions  from  the  SICC.  Since  offers 
are  generally  not  made  for  active  NSN  SSRs ,  no  offer  reply  pro¬ 
cessing  takes  place  in  this  category. 

a.  File  Maintenance.  This  major  event  consists  of  two 
subevents  to  process  followup  transactions  from  the  SICC. 

(1)  These  transactions,  like  the  original  SSR  trans 
actions  are  first  looked  at  in  the  Control  Branch.  Each  transac 
tion  is  scanned  for  the  PCC/ACF  combination  which  is  checked 
against  the  control  register  to  determine  the  assigned  cataloger 
Each  transaction  is  hand  carried  to  the  responsible  cataloger. 

(2)  When  the  cataloger  receives  a  followup  from  the 
submitting  activity,  he  checks  the  history  files  to  determine  if 
the  item  has  been  completed.  If  the  item  is  not  in  the  history 
file,  the  active  files  are  checked  to  find  where  the  item  is  in 
the  processing  cycle.  The  cataloger  then  prepares  a  letter  to 


to  the  submitting  activity  relating  the  advice  if  the  item  was 
completed,  the  status  if  the  item  is  still  being  processed,  or 
no  record  if  the  item  is  not  found.  The  letter  is  then  mailed 
to  the  submitting  activity. 

J  .  CIMM  INACTIVE  NSN/PSCN  SSR  PROCESSING 

The  phases  and  major  events  included  in  incoming  CIMM  inac¬ 
tive  NSN/PSCN  SSR  processing  are  shown  in  Figure  11-10.  The  work 
flow  relating  phases  and  major  events  to  subevents  and  organiza¬ 
tional  elements  are  illustrated  in  Figure  11-12. 

1.  SICC  SSR  Processing  Phase.  SSR  transactions  are  gener¬ 
ated  and  forwarded  to  TARCOM  by  SICC  activities  in  this  phase. 

2.  CIMM  SSR  Processing  Phase.  This  processing  phase  is 
made  up  of  ten  major  events  shown  in  Figure  I  I - 1 0 .  These  major 
events  include  E d i t / Val i da t io n  ,  Catalog  Data  Screening,  Advice 
Decision,  File  Maintenance,  Advice  Decision,  Catalog  Actions, 
Method/ Level  of  Support,  Requirements  Determination,  Advice 
Decision  and  File  Maintenance.  As  with  active  NSNs,  this  cate¬ 
gory  of  items  is  processed  on  a  PCC  package  basis  until  they 
reach  the  fourth  major  event  where  they  begin  processing  on  an 
item  basis. 

a.  Ed i t / Va 1 i d a t i o n .  All  processing  in  this  major  event 
is  identical  to  that  in  subsection  1. 2. a.  above. 

b.  Catalog  Data  Screening.  Processing  in  this  major 
event  is  identical  to  that  in  subsection  I.2.b.  above,  with  one 
exception.  Only  NSNs  are  screened  against  DLSC  files;  PSCNs  are 
not  screened  against  DLSC  files. 

c.  Advice  Decision.  Processing  in  this  major  event  is 
identical  to  that  in  subsection  I.2.C  above  with  the  addition 
that  rejects  may  include  invalid  PSCNs  or  PSCNs  assigned  for  man¬ 
agement  to  another  IMM.  These  rejects  are  processed  identically 
to  NSN  rejects. 

d.  File  Maintenance.  This  major  event  consists  of  the 
three  subevents  shown  in  Figure  11-12. 

(1)  SSR  transactions  for  which  reject  advice  tran¬ 
sactions  were  mailed  to  the  SICC  are  filed  in  the  history  file 
discussed  in  section  1.  above. 

(2)  As  with  active  NSN  items,  those  not  rejected 
are  supported;  however,  exactly  how  they  will  be  supported  has 
not  yet  been  determined.  These  items  are  forwarded  by  the  cata- 
loger  to  the  Initial  Materiel  Support/Provisioning  Office  (IMSO) 


Figure  11-12 
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File  Maintenance  (l)  Transfer  Items  to 
History  File 


within  DM.  Here  item  data  is  extracted  from  the  Contract  History 
File  for  inactive  NSNs.  The  cataloger  begins  the  1MM  processing 
time  established  by  the  1MM  manual  upon  transfer  of  items  to 
IMSO. 


(3)  This  data,  along  with  SSR  data,  is  used  to  re¬ 
establish  the  item  on  the  PMR  and  local  TIR  files.  In  addition, 
PSCN  items  are  established  on  the  PMR  and  local  TIR  files  by 
this  office.  For  those  items  established  on  the  PMR  and  local 
TIR  files,  item  selection  worksheets  are  prepared  and  forwarded 
to  the  cataloger. 

e.  Advice  Decision.  This  major  event  consists  of  four 
subevents  resulting  in  offer  or  reject  advices. 

(1)  During  the  process  of  establishing  these  items 
on  the  PMR  and  local  TIR  files,  an  active  NSN  item  substitute 
may  be  identified.  When  this  occurs,  processing  by  IMSO  for 
these  items  is  terminated,  and  the  original  item  and  active  NSN 
item  substitute  is  returned  to  the  cataloger  for  action. 

(2)  Each  SSR  item  returning  from  IMSO  processing  is 
reviewed  to  identify  actions  required  by  the  cataloger.  Items 
returned  with  a  substitute  are  separated  from  those  returned 
with  an  item  selection  worksheet. 

(3)  An  offer  advice  transaction  is  formatted  by  the 
cataloger  for  each  substitute  and  forwarded  to  DMIS  for  keypunch¬ 
ing  . 

(4)  The  offer  advice  transactions  are  mailed  to  the 
appropriate  SICC  by  the  cataloger  and  a  60-day  suspense  is  placed 
on  each  one.  SSR  transactions  for  these  items  remain  in  the 
active  file  during  the  suspense  period.  If  an  offer  reply  Is  not 
received  during  the  60-day  suspense  period,  a  reject  advice  trans¬ 
action  containing  ATC  '08'  (no  reply  to  an  offer)  is  formatted 

by  the  cataloger,  keypunched  in  DMIS  and  mailed  to  the  SICC  by 
the  cataloger-  When  the  reject  advice  transaction  is  mailed,  the 
SSR  transactions  for  the  item  are  filed  in  the  history  file. 

f.  Catalog  Actions.  This  major  event  is  made  up  of 
three  subevents  to  request  reactivation  or  NUN  assignment  from 
DLSC . 


(1)  Items  returned  with  an  item  selection  worksheet 
require  either  preparation  of  catalog  transactions  to  reactivate 
inactive  NSN  items  or  preparation  of  cataloging  transactions 
requesting  NUN  assignment  for  PSCN  items.  These  transactions 
are  formatted  by  the  cataloger  and  forwarded  to  the  Control 
Branch.  At  the  same  time,  each  item  is  sent  to  the  appropriate 
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item  manager  for  determination  of  ATC  and  support  date.  The 
cataloger  suspenses  the  item  manager  on  a  10-day  basis  to  make 
these  determinations  as  with  active  NSN  items  discussed  above. 


(2)  The  Control  Branch  performs  a  quality  review  of 
the  catalog  transactions  before  they  are  batched  for  input  to 
CCSS. 

(3)  DMIS  inputs  the  catalog  transactions  to  the 
next  CCSS  processing  cycle  through  which  they  are  forwarded  to 
DLSC. 


g.  Method/Level  of  Support.  This  major  event  consists 
of  a  single  subevent  to  assign  an  AAC . 

(1)  The  item  manager  reviews  each  item  forwarded  to 
him  by  the  cataloger.  The  replenishment  quantity  and  PLT  are 
used  in  determining  the  method  and  level  of  support  and  assign¬ 
ing  an  AAC. 


h.  Requirements  Determination.  This  major  event  con¬ 
sists  of  a  single  subevent. 

(1)  After  the  AAC  is  determined,  the  item  manager 
performs  requirements  determination  and  initiates  procurement 
action  when  necessary. 

i.  Advice  Decision.  This  major  event  consists  of  three 
subevents  to  provide  accept  advice  to  the  SICC. 

(1)  The  AAC  in  conjunction  with  the  Replenishment 
Quantity,  PLT  and  DRPR  are  used  to  determine  the  ATC  and  support 
date  to  be  returned  to  the  SICC.  The  ATC  and  alternate  support 
date  (if  required)  are  annotated  on  each  SSR  transaction  and 
returned  to  the  cataloger. 

(2)  The  cataloger  uses  this  information  to  format 
an  initial  accept  advice  transaction  to  the  SICC.  These  advice 
transactions  are  keypunched  in  DMIS  and  returned  to  the  cata¬ 
loger. 


(3)  The  accept  advice  transactions  are  mailed  to 
the  SICC  under  cover  of  a  letter  prepared  by  the  cataloger. 

j.  File  Maintenance.  This  major  event  consists  of  four 
subevents  to  complete  processing  for  this  category  of  items  and 
provide  a  history  record  of  items  completed. 
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(1)  The  original  SSR  transactions  are  retained  in 
the  active  file  until  a  notification  is  received  from  DLSC  that 
the  inactive  NSN  has  been  reactivated  or,  in  the  case  of  a  PSCN, 
an  assigned  NUN  is  received. 

(2)  When  these  notifications  are  received,  an  NSN 
notification  is  formatted  by  the  cataloger.  NSN  notification 
transactions  are  keypunched  by  DMIS  and  returned  to  the  cata¬ 
loger. 


(3)  The  cataloger  mails  the  NSN  notification  to  the 

SICC. 

(4)  The  original  SSR  transactions  are  then  trans¬ 
ferred  from  the  active  file  to  the  history  file  with  the 
assigned  NSN  annotated  on  the  transactions. 

3.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
occurs  at  SICC  activities  to  process  advice  transactions  gener¬ 
ated  by  TARCOM.  When  an  offer  advice  transaction  is  received  by 
the  SICC,  it  is  required  by  the  IMM  Manual  to  review  the  offer 
and  provide  an  offer  reply  transaction  to  the  IMM  indicating 
acceptance  or  rejection  of  the  offered  item.  Also  if  the  SICC 
does  not  receive  an  advice  transaction  within  35  days  of  SSR 
transaction  submittal,  it  may  generate  a  followup  transaction 
and  either  mail  it  or  transmit  it  via  AUTODIN  to  TARCOM. 

4.  CIMM  Followup/Offer  Reply  Processing  Phase.  This  pro¬ 
cessing  phase  completes  the  processing  cycle  for  incoming  SSR 
transactions.  This  phase  consists  of  four  major  events  for 
inactive  NSN/PSCN  SSRs  at  TARCOM.  These  major  events  are  shown 
in  Figure  11-10  and  the  work  flow  within  them  is  shown  in  Figurr 
11-12.  Resubmissions  are  treated  as  initial  submission  SSR 
transactions  and  processed  as  such. 

a.  File  Maintenance.  This  major  event  consists  of  four 
subevents  to  process  followups  and  offer  replies. 

(1)  These  transactions,  like  the  original  SSR  trans¬ 
actions,  are  first  looked  at  in  the  Control  Branch.  Each  trans¬ 
action  is  scanned  for  the  PCC/ACF  combination  which  is  checked 
against  the  control  register  to  determine  the  assigned  cataloger 
to  whom  it  is  hand-carried. 

(2)  When  the  cataloger  receives  a  followup  trans¬ 
action  from  the  submitting  activity,  he  checks  the  history  files 
to  determine  if  the  item  has  been  completed.  If  the  item  is  not 
there,  the  active  files  are  checked  to  find  its  location  in  the 
processing  cycle.  The  cataloger  then  prepares  a  letter  to  the 
submitting  activity  relating  advice  if  the  item  was  completed. 
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status  If  the  item  is  still  being  processed,  or  no  record  if  the 
item  is  not  found.  The  letter  is  then  mailed  to  the  submitting 
activity. 

(3)  The  cataloger  pulls  initial  submission  SSR 
transactions  matching  offer  reply  transactions  from  the  active 
file. 

(4)  When  an  offered  item  is  rejected  by  the  SICC, 
the  cataloger  forwards  the  original  item  back  to  DM  to  begin 
processing  at  the  point  the  substitute  item  was  identified. 

From  that  point  forward  the  item  is  processed  as  discussed  above 
beginning  with  subsection  2.e(l). 

b.  Catalog  Actions.  This  major  event  consists  of  three 
subevents  to  identify  required  catalog  actions  and  transmit  them 
to  DLSC. 

(1)  If  the  offer  is  accepted  by  the  SICC,  the  cata¬ 
loger  determines  if  catalog  transactions  need  to  be  generated  to 
add  the  SICC  as  a  registered  user  of  the  offered  item  on  the  local 
TIR  and  DLSC  files.  Formatted  catalog  transactions  are  taken  to 
the  Control  Branch. 

(2)  The  Control  Branch  performs  a  quality  review  on 
the  catalog  transactions  before  entering  them  on  remote  terminals 
for  automated  processing. 

(3)  DMIS  inputs  the  batched  transactions  into  the 
next  CCSS  processing  cycle  where  update  transactions  are  for¬ 
warded  to  DLSC. 

c.  Requirements  Determination.  This  major  event  con¬ 
sists  of  two  subevents. 

(1)  The  cataloger  notifies  the  item  manager  of 
acceptance  of  an  offered  item  and  includes  the  offered  item  NSN 
and  appropriate  SSR  data  such  as  retail  and  replenishment  re¬ 
quirements  . 

(2)  The  item  manager  uses  this  information  in  con¬ 
junction  with  his  records  to  budget  and  forecast  for  SSR  require¬ 
ments  and  initiate  procurement  action  when  necessary. 

d.  File  Maintenance.  This  major  event  consists  of  a 
single  event  to  provide  a  history  record  of  these  items  and 
complete  the  processing  for  this  category  of  items. 

(1)  When  the  cataloger  has  forwarded  the  required 
information  to  the  item  manager  end  has  taken  required  catalog 
actions,  these  SSR  transactions  are  considered  complete  and  are 
transferred  to  the  history  file. 


CIMM  PART  NUMBER  SSR  PROCESSING 


The  phases  and  major  events  included  in  incoming  CIMM  Part 
Number  SSR  Processing  are  shown  in  Figure  11-10.  The  work  flow 
relating  subevents  and  organizations  to  major  events  and  phases 
are  illustrated  in  Figure  11-13* 

1.  SICC  SSR  Processing  Phase.  Part  Number  SSR  transactions 
are  generated  by  SICC  activities  and  forwarded  by  mail  along  with 
supporting  technical  data  or  item  name  transactions. 

2.  CIMM  SSR  Processing  Phase.  This  processing  phase  con¬ 
sists  of  major  events  shown  in  Figure  Il-iO  and  include  Edit/ 
Validation,  Catalog  Data  Screening,  Advice  Decision,  File  Mainte¬ 
nance,  Catalog  Data  Screening,  Advice  Decision,  File  Maintenance, 
Catalog  Actions,  Method/Level  of  Support,  Advice  Decision,  Re¬ 
quirements  Determination  and  File  Maintenance.  This  category  of 
items  is  processed  on  a  PCC  package  basis  until  completion  of 

the  third  major  event  where  processing  on  an  item  basis  begins. 

a.  Edit/Validation.  Processing  in  this  major  event  is 
the  same  as  that  discussed  in  subsection  I.2.a.  above. 

b.  Catalog  Data  Screening.  Processing  in  this  major 
event  is  the  same  as  that  described  in  subsection  I.2.b.  above, 
except  that  part  numbers  are  not  screened  against  DLSC  files  at 
this  processing  point  as  shown  in  Figure  11-13. 

c.  Advice  Decision.  Processing  in  this  major  event  is 
the  same  as  that  described  in  subsection  I.2.c.  above  with  a 
single  addition  as  shown  in  Figure  11-13.  Subevent  c.(l)  in 
this  figure  includes  a  review  of  the  technical  data  submitted 
with  the  Part  Number  SSR  transactions.  SSR  transactions  may  be 
rejected  when  this  review  indicates  the  technical  data  is  in¬ 
adequate  or  incomplete. 

d.  File  Maintenance.  Processing  in  this  major  event  is 
identical  to  that  described  in  subsection  I.2.d.  above. 

e.  Catalog  Data  Screening.  There  are  five  subevents 
included  in  this  major  event  as  shown  in  Figure  11-13. 

(1)  Part  Number  items  not  rejected  are  forwarded  to 
the  Secondary  Item  Engineering  Evaluation  Branch  within  DE.  Here 
the  SSR  transactions  and  accompanying  technical  data  are  reviewed 
to  ensure  procurement  of  the  item  is  possible.  The  cataloger 
begins  the  IMM  processing  time  established  by  the  IMM  Manual  upon 
transfer  of  items  to  DE. 
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c.  Advice  Decision  (1)  Review  Screening  Re¬ 
sults  &  Technical  Data 


to  Cataloger  from  IMSO 


Figure  11-13 


Figure  11-13 


(2)  Each  item  is  manually  screened  against  a  number 
of  manufacturer's  catalogs  residing  in  the  branch  to  determine 
if  a  suitable  substitute  item  exists.  When  procurement  can  be 
made  and  no  substitutes  are  identified,  the  item  is  forwarded  to 
the  Initial  Materiel  Suppor t /Proc urement  Office  (IMSO)  within  DM. 

(3)  The  initial  Materiel  Suppor t /Provisioning  Office 
prepares  input  transactions  to  lodge  new  items  on  the  PMR  file. 
These  transactions  are  forwarded  to  DMIS  for  input  to  CCSS. 

(4)  DMIS  inputs  these  transactions  into  the  CCSS 
Provisioning  Subsystem  to  establish  them  on  the  PMR.  This  auto¬ 
matically  results  in  a  DLSC  screening  transactions  being  gener¬ 
ated  and  forwarded  to  DLSC.  Returns  from  DLSC  go  back  into  CCSS 
for  printing.  Hard  copy  results  are  returned  to  IMSO  for  anal¬ 
ysis. 


(5)  The  results  from  DLSC  screening  are  reviewed  in 
IMSO  and  fall  into  one  of  three  categories  -  the  part  number 
exactly  matches  to  an  active  NSN,  the  part  number  matches  a  pos¬ 
sible  substitute  item,  or  a  no  match  occurs.  For  items  remaining 
unmatched  after  this  screening  process,  an  item  selection  work¬ 
sheet  is  prepared.  The  item  selection  worksheet  and  original 
item  data  is  returned  to  the  cataloger. 

f.  Advice  Decision.  This  major  event  consists  of  seven 
subevents  and  results  in  offer  or  reject  advice  to  the  S1CC. 

(1)  Items  not  forwarded  to  IMSO  by  DE  are  items  for 
which  a  substitute  item  was  identified  or  items  for  which  a  sub¬ 
stitute  item  was  not  identified  and  the  accompanying  technical 
data  is  not  sufficient  for  procurement  of  the  requested  item. 
These  items  are  returned  to  the  cataloger  for  preparation  of 
advice  transactions. 

(2)  Items  which  received  an  exact  match  or  a  pos¬ 
sible  substitute  match  from  DLSC  screening  are  returned  to  the 
cataloger  for  further  processing. 

(3)  Items  returned  by  DE  and  IMSO  are  reviewed  to 
determine  the  processing  action  required. 

(4)  Items  for  which  substitutes  were  identified 
have  offer  advice  transactions  formatted.  Items  for  which  tech¬ 
nical  data  is  not  sufficient  for  procurement  or  received  an 
exact  match  from  DLSC  to  an  NSN  managed  by  another  IMM  are 
assigned  a  reject  ATC  and  reject  advice  transactions  are  for¬ 
matted. 
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(5)  Reject  advice  transactions  and  offer  advice 
transactions  are  keypunched  in  DMIS  and  returned  to  the  cata- 
loger . 

(6)  The  offer  and  reject  advice  transactions  are 
mailed  to  the  appropriate  SICC  along  with  technical  data  sub¬ 
mitted  for  the  original  items  rejected  and  an  explanation  for 
the  reject. 


(7)  Items  returned  from  IMSO  which  matched  exactly 
to  an  active  NSN  managed  by  TARCOM  are  processed  as  if  the  SSR 
transactions  submitted  contained  an  active  NSN.  In  this  case, 
the  items  are  forwarded  to  the  item  manager  for  Requirements 
Determination  processing  and  continue  as  described  in  subsection 
I.2.e  above.  These  actions  are  not  shown  on  Figure  11-13. 

g.  File  Maintenance.  This  major  event  consists  of  a 
single  subevent. 

(1)  Rejected  item  SSR  transactions  are  transferred 
to  the  history  file.  SSR  transactions  for  which  an  offer  advice 
was  sent  to  the  SICC  remain  in  the  active  file  under  the  60-day 
suspense . 

h.  Catalog  Actions.  This  major  event  consists  of  four 
subevents  as  shown  in  Figure  11-13  to  prepare  NUN  requests  and 
establish  new  items  on  the  local  TIR  File. 

(1)  Items  returned  from  IMSO  with  an  item  selection 
worksheet  require  preparation  of  cataloging  transactions  request¬ 
ing  NUN  assignment  from  DLSC.  In  addition,  transactions  are 
formatted  to  establish  the  item  on  the  local  TIR  file.  These 
transactions  are  hand-carried  to  the  Control  Branch. 

(2)  The  Control  Branch  performs  a  quality  review  of 
these  transactions  before  they  are  input  for  CCSS  processing. 

(3)  The  transactions  are  input  to  the  next  pro¬ 
cessing  cycle  of  CCSS  where  each  item  is  established  on  the  local 
TIR  file  and  a  NUN  request  is  processed  for  AUTODIN  transmittal 
to  DLSC. 


(4)  The  cataloger  monitors  the  local  TIR  File  until 
the  item  has  been  established  on  this  file.  Each  item  is  then 
forwarded  to  the  item  manager  for  further  processing. 

i.  Method/Level  of  Support.  This  major  event  consists 
of  a  single  subevent  to  make  final  determination  of  AAC . 
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(1)  When  the  item  manager  receives  these  items  from 
the  cataloger,  he  reviews  the  SSR  wholesale  requi rement s ,  PLT , 

AAC ,  and  DRPR  submitted  by  the  SICC  for  each  item  and  determines 
the  AAC  under  which  each  item  will  be  managed. 

j •  Advice  Decision.  This  major  event  consists  of  four 
subevents  resulting  in  initial  accept  advice  to  the  SICC  as  shown 
in  Figure  11-13. 

(1)  The  assigned  AAC,  PLT  and  DRPR  are  analyzed  by 
the  item  manager  to  determine  the  ATC  and  support  date  to  be 
returned  to  the  SICC. 

(2)  The  ATC  determined  and  the  support  date,  if 
greater  than  the  DRPR,  are  annotated  on  the  SSR  transactions 
before  they  are  returned  to  the  cataloger. 

(3)  Accept  advice  cards  are  formatted  by  the  cata¬ 
loger  and  keypunched  in  DMIS. 

(4)  The  cataloger  mails  the  advice  cards  to  the 
SICC.  Since  a  NUN  has  not  yet  been  assigned  to  these  items, 
they  remain  in  the  active  file. 

k.  Requirements  Determination.  This  major  event  con¬ 
sists  of  a  single  subevent. 

(1)  After  the  assignment  of  AAC  and  determination 
of  ATC  and  support  date,  the  item  manager,  based  on  the  AAC, 

DRPR  and  PLT,  decides  if  procurement  action  is  necessary,  and  if 
so ,  initiates  it  . 

l.  File  Maintenance.  There  are  five  subevents  included 
in  this  major  event  to  update  automated  files,  provide  NSNs  to 
the  SICC,  and  provide  history  records  for  items  completed. 

(1)  When  the  accept  advice  cards  are  mailed  to  the 
SICC,  the  cataloger  prepares  a  notification  to  IMSO  containing 
all  items  for  which  a  NUN  request  was  transmitted  to  DLSC. 

(2)  Notifications  to  IMSO  results  in  formatting  of 
PMR  File  and  local  TIR  File  update  transactions  which  are  for¬ 
warded  to  DMIS  for  input  to  the  next  processing  cycle  of  CCSS. 

(3)  When  NSN  assignment  transactions  are  received 
they  pass  through  DMIS  to  the  cataloger.  The  SSR  transactions 
are  pulled  from  the  active  file  when  the  NUN  assignment  is 
received  by  the  cataloger  and  the  assigned  NSN  is  annotated  on 
the  SSR  transactions. 
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(4)  The  cataloger  then  formats  an  NSN  notification 
transaction  for  each  NSN  received  to  provide  the  assigned  NSN  to 
the  SICC.  The  NSN  notifications  are  keypunched  in  DM1S. 

(5)  The  keypunched  NSN  notification  transactions 
are  mailed  to  the  appropriate  SICC  and  the  SSR  transactions  are 
transferred  to  the  history  file. 

3.  SICC  SSR  Advice  Processing  Phase.  See  subsection  J.3. 
above  for  description  of  this  phase. 

4.  CIMM  Followup/Offer  Reply  Processing  Phase.  This  pro¬ 
cessing  phase  completes  the  cycle  for  incoming  Part  Number  SSRs 
submitted  to  TARCON.  It  is  made  up  of  four  major  events  shown 
in  Figure  11-10:  File  Maintenance,  Catalog  Actions,  Requirements 
Determination,  and  File  Maintenance.  Re s u bm 1 s s 1 on s  are  treated 
as  initial  submission  SSRs  and  processed  as  such. 

a.  File  Maintenance.  This  major  event  consists  of  five 
subevents  to  process  followups  and  offer  replies. 

(1)  Actions  under  this  subevent  are  identical  to 
those  described  under  subsection  J.4.a.(l)  above. 

(2)  Actions  under  this  subevent  are  identical  to 
those  described  under  subsection  J.4.a.(2)  above. 

(3)  Actions  under  this  subevent  are  identical  to 
those  described  under  subsection  J.4.a.(3). 

(4)  When  the  response  to  the  offered  item  is  nega¬ 
tive  (the  offer  is  rejected),  the  cataloger  returns  the  item  to 
the  processing  point  where  the  substitute  item  was  identified 
either  DE  (subsection  2.e.(2))  or  DM  (subsection  2.e.(5))  and 
processing  continues  as  described  above. 

(5)  When  the  offered  item  is  a  part  number  and  the 
reply  is  accept,  the  cataloger  forwards  the  LISSR  transaction 
package  to  the  Initial  Materiel  Support/Provlsioning  Office  to 
establish  the  item  on  the  PMR  File.  Processing  actions  on  these 
items  are  the  same  as  any  other  new  part  number  item  beginning 
with  subsection  2.e.(5)  above.  The  single  exception  to  this  is 
that  only  an  NSN  notification  is  prepared  and  mailed  to  the  SICC 
an  accept  advice  transaction  is  not  sent  to  the  SICC. 

b.  Catalog  Actions.  This  major  event  takes  place  for 
NSN  offers  accepted.  Processing  in  this  major  event  is  iden¬ 
tical  to  that  discussed  in  subsection  J.4.b. 
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c.  Requirements  Determination.  This  major  event  occurs 
for  NSN  offers  accepted.  Processing  is  identical  to  that  dis¬ 
cussed  in  subsection  J.4.c. 

d.  File  Maintenance.  This  major  event  completes  the 
processing  cycle  and  occurs  for  NSN  offers  accepted.  Processing 
Is  Identical  to  that  discussed  in  subsection  J.4.d. 
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CHAPTER  III 


NAVY 


A.  INTRODUCTION 


There  are  two  activities  in  the  Navy  which  generate  SSR  trans¬ 
actions  as  a  SICC  and  process  incoming  SSRs  as  a  WIMM.  These 
activities  are  the  Navy  Inventory  Control  Points  (ICPs):  the  Ships 
Parts  Control  Center  (SPCC)  and  the  Aviation  Supply  Office  (ASO). 
The  Operational  Implementation  Review  took  place  at  SPCC. 

The  automated  operational  system  at  SPCC  is  discussed  first 
to  illustrate  the  extent  of  implementation  of  the  system  described 
in  Part  1  of  this  Volume.  This  is  followed  by  a  discussion  of  the 
organizational  elements  Involved  in  the  generation  and  processing 
of  outgoing  and  incoming  SSRs.  Descriptions  of  the  generation  of 
outgoing  provisioning  SSR  transactions,  outgoing  nonprovisioning 
SSR  transactions,  and  incoming  provisioning  and  nonprovisioning 
SSR  transactions  in  terms  of  phases,  major  events,  and  subevents 
are  provided  separately. 

B.  NAVY  AUTOMATED  OPERATIONAL  SYSTEM 


There  are  two  automated  provisioning  subsystems  operational 
at  SPCC.  One  subsystem  is  used  for  provisioning  electronics 
components;  the  other  is  used  in  provisioning  Hull,  Mechanical, 
Electrical  and  Ordnance  (HME&O)  equipments.  The  provisioning 
subsystem  and  SSR  related  applications  reviewed  for  operational 
implementation  was  that  used  for  HME&O  equipments.  The  other 
subsystem  was  not  reviewed  because  of  time  limitations,  avail¬ 
ability  of  functional  system  documentation  and  similarity  of 
SSR  processing  after  Initial  generation. 

1.  Operational  Implementation.  The  SSR  application  was 
split  into  two  phases;  each  to  be  designed,  programmed  and  im¬ 
plemented  totally  independent  of  one  another.  The  design  and 
program  module  portions  discussed  in  Part  1  of  this  Volume  show 
this  independent  development. 

a.  SICC  SSR  Processing  (Phase  I).  This  phase  of  the  SSR 
application  was  completed  and  distributed  for  implementation  by 
FMSO  in  March  1978  for  concurrent  implementation  with  the  new 
IMM  Manual.  Both  ICPs  then  began  interface  testing  of  the  appli¬ 
cation.  With  the  implementation  of  Phase  I  at  SPCC  in  October 
1978,  Phase  I  has  now  been  Implemented  at  both  ICPs.  As  a  result. 
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SPCC  from  May  to  October  1978  was  using  an  alternate  method  of 
producing  their  SSRs.  This  alternate  method  or  Interim  SSR  pro¬ 
cess  was  being  used  during  the  Operational  Implementation  Review 
and  is  discussed  below. 

b.  WIMM  SSR  Processing  (Phase  II).  This  phase  was  ori¬ 
ginally  scheduled  to  be  completed  and  distributed  for  implemen¬ 
tation  toward  the  end  of  1978.  However,  because  of  the  low  vol¬ 
ume  of  WIMM  SSRs  received,  the  ICPs  placed  a  lower  priority  on 
completing  this  phase  than  that  placed  on  completing  Phase  I. 

The  programming  of  Phase  II  had  not  yet  been  completed  at  the 
time  of  completion  of  the  DODSSR  research.  As  a  result,  WIMM 
SSR  processing  was  done  at  SPCC  on  a  strictly  manual  basis.  This 
manual  process  is  discussed  later  in  this  section. 

2.  Operational  System  Description.  The  automated  system  in 
operation  at  the  time  of  the  implementation  review  is  shown  in 
Figure  III-l.  This  system  applies  to  HME&O  equipments  only,  and 
is  applicable  to  outgoing  provisioning  and  nonprovisioning  SSR 
and  LIAC  transactions.  The  SPCC  HME&O  Provisioning  Subsystem 
and  the  UICP  Wholesale  Requirements  Computation  Application  shown 
in  this  figure  are  discussed  in  Part  1  of  this  Volume.  The  re¬ 
mainder  of  the  Application/Program  Module  blocks  are  different 
from  those  discussed  or  are  not  discussed  in  Part  1  of  this  Volume. 
Two  additional  applications  not  shown  in  this  figure,  but  discussed 
in  Part  1  as  part  of  the  provisioning  process  as  stand-alone  appli¬ 
cations  are  the  UICP  Provisioning  Monitoring  Application  and  the 
UICP  Provisioning  Screening  Application. 

a  *  UICP  -  SPCC  Provisionlng/SSR  Interface  Application 
(OLD) .  This  interface  application  is  similar  to  the  one  dis¬ 
cussed  in  Part  1  of  this  Volume  in  that  it  takes  transactions 
after  the  requirements  determination  process,  processes  them 
through  the  SSR  generation  criteria  (Part  1,  Figure  III-3)  and 
produces  SSR  candidates  and  an  Activity  Control  Number  (ACN) 
file.  These  SSR  candidates  are  in  the  pre-IMM  Manual  formats  in 
use  before  1  May  1978. 

b.  UICP  SSR  Application  (OLD).  This  application,  like 
the  one  discussed  above,  processes  SSR  transactions  in  the  old 
f  ormat  s . 

(1)  Inputs .  Inputs  to  this  application  include: 

(a)  Outgoing  provisioning  SSR  candidates; 

(b)  SSR  advice  transactions  from  IMMs; 

(c)  Manually  generated  outgoing  provisioning 

SSR  transactions; 
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(d)  SSR  suspense  file  updates. 

(2)  Flies.  The  single  file  accessed  by  this  appli¬ 
cation  is  the  SSR  Suspense  File  shown  in  Figure  III-l.  This  is 

a  magnetic  tape  file  made  up  of  fixed  length  (175  character) 
records  in  PCC ,  DOR,  ACF,  ISN  and  Type  Format  Code  sequence.  This 
Format  Code  is  a  Navy  unique  code  indicating  whether  the  record 
is  a  PDSSR,  LISSR,  etc.  Only  valid  provisioning  SSR  transactions 
(initial  submission  and  changes)  are  posted  to  this  file.  There 
is  no  automatic  purge  of  this  file;  manual  action  through  the 
SSR  suspense  file  updates  is  used  to  delete  records  from  the  file. 

( 3 )  Processing 

Generally  processing  consists  of  validation  of 
input  transactions  with  transactions  in  error  printed  on  the  SSR 
Error  Transaction  List.  Valid  transactions  are  posted  to  the  SSR 
Suspense  File,  printed  on  the  SSR  Valid  Transaction  List,  and 
punched  out  as  outgoing  SSR  transactions. 

SSR  Suspense  File  update  transactions  are  pro¬ 
cessed  last  and  are  used  to  extract  information  from  the  SSR 
Suspense  File  and  purge  records  from  the  file. 

(4)  Outputs  .  Outputs  from  this  application  include: 

(a)  Valid  Outgoing  Provisioning  SSR  Transactions 
in  the  old  formats. 

(b)  SSR  Valid  Transactions  List. 

(c)  SSR  Error  Transactions  List. 

(d)  SSR  Suspense  File  Lists. 

c.  SPCC  SSR  "Bridge"  Program  Module.  There  is  a  final 
Program  Module  shown  on  Figure  III-l  which  was  designed,  devel¬ 
oped,  programmed  and  implemented  by  SPCC.  This  program  module 
was  developed  to  receive  the  outgoing  SSR  transactions  produced 
in  the  UICP  SSR  Application  (OLD)  and  convert  these  transactions 
to  the  new  formats  required  by  the  implementation  of  the  IMM 
Manual  on  1  May  1978.  This  program  module  allowed  SPCC  to  gener¬ 
ate  and  process  outgoing  provisioning  SSRs  after  1  May  1978  in 
the  same  manner  as  they  had  been  prior  to  1  May  1978.  This  opera¬ 
tional  system  was  to  be  used  until  the  UICP-SPCC  Provisionlng/SSR 
Interface  and  UICP  SPCC  Applications  discussed  in  Part  1  of  this 
Volume  completed  Interface  testing  and  were  implemented  at  SPCC. 
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SPCC  is  responsible  for  determining  support  items  required 
for  each  provisioning  project.  These  support  items  are  selected 
and  undergo  method  of  management  determinations  to  indicate  the 
support  items  to  be  retained  for  management  by  SPCC  and  the  sup¬ 
port  items  to  be  managed  by  other  activities  and  requested  via 
SSRs  or  NIMSRs.  Method  and  level  of  support  decisions  are  made 
for  items  retained  by  SPCC  for  management.  SPCC  also  has  respon¬ 
sibility  for  processing  and  providing  advice  for  incoming  SSRs 
as  a  WIMM.  The  particular  organizational  elements  involved  in 
carrying  out  these  responsibilities  for  HME&O  and  Electronics 
Equipments  are  shown  in  Figure  III-2. 

Primary  processing  of  outgoing  and  incoming  SSR  transactions 
is  within  the  Weapons  Systems  Support  Group.  There  are  two  divi¬ 
sion  level  organizational  elements  providing  administrative  sup¬ 
port.  Each  of  the  organizational  elements  at  the  lowest  level 
will  be  discussed  indicating  the  specific  SSR  generation  and 
processing  functions  they  perform. 

1.  Weapons  Systems  Support  Group.  The  Weapons  Systems 
Support  Group  contains  the  largest  number  of  organizational  ele¬ 
ments  involved  with  SSR  generation  and  processing.  The  pro¬ 
cessing  functions  are  the  responsibility  of  four  divisions:  the 
Ships  Division,  the  Ordnance  Division,  the  Electronics  Division 
and  the  Data  Control  Division. 

(a)  Ships  Division.  SSR  generation  and  processing  within 
this  division  lies  within  two  branches:  the  Program  Management 
Branch  and  the  HM&E  Provisioning  Branch. 

(1)  Program  Management  Branch  (PMB).  The  Clerical 
Screening  and  Distribution  Section  (CSDS)  within  this  branch  is 
where  PTD  is  initially  received  from  the  contractor  and  reviewed 
for  adequacy.  This  section  is  responsible  for  assigning  a  Pro¬ 
visioning  Document  Control  Number  (PDCN)  and  establishing  a  pro¬ 
ject  folder  for  each  provisioning  project  received.  This  branch 
begins  coding  of  provisioning  forms  and  establishes  each  project 
in  the  Provisioning  Monitoring  File  (PMF).  Inadquate  PTD  pack¬ 
ages  along  with  documentation  citing  the  deficiencies  are  returned 
to  the  contractor  by  this  section. 

(2)  HM&E  Provisioning  Branch.  This  branch  performs 
provisioning  functions  for  HM&E  equipments.  Personnel  performing 
these  functions  are  equipment  technicians  and  are  referred  to  as 
provis ioner s  .  They  do  a  complete  review  of  the  PTD  submitted  by 
the  contractor  and  document  all  deficiencies  found  that  must  be 
corrected  by  the  contractor.  The  provisioner  assigns  the  program 
data  for  the  project  and  establishes  new  equipments  on  the  Weapons 
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Systems  File  (WSF).  The  provisioner  determines  the  range  and 
depth  of  support  items  and  assigns  SM&R  codes  and  other  technical 
data  when  required.  He  is  responsible  for  approving  or  denying 
items  offered  as  substitutes  and  makes  final  determinations  on 
possible  NSN  matches  resulting  from  catalog  data  screening.  He 
also  makes  the  determination  of  whether  requirements  will  be 
computed  manually  or  on  an  automated  basis.  When  requirements 
are  to  be  computed  manually,  the  provisioner  performs  this  func¬ 
tion. 


b.  Ordnance  Division.  This  division  is  made  up  of  six 
branches  each  of  which  is  assigned  separate  groups  of  equipments. 
Each  branch  generally  performs  the  same  functions  discussed  for 
the  HM&E  Provisioning  Branch  in  the  Ships  Division. 

c.  Electronics  Division.  This  division  is  divided 
into  six  branches  by  type  of  electronic  equipment.  Each  branch 
generally  performs  the  same  functions  discussed  for  the  HM&E 
Provisioning  Branch  of  the  Ships  Division. 

d.  Data  Control  Division.  Four  branches  of  this  divi¬ 
sion  are  involved  in  SSR  generation  and  processing.  While  the 
divisions  discussed  above  are  primarily  concerned  with  provi¬ 
sioning  outgoing  SSRs,  this  division  is  involved  with  Outgoing 
and  Incoming  Provisioning  and  Nonprovisioning  SSR  items. 

( 1 )  Item  Entry  Branch  (IEB) 


This  branch  is  made  up  of  personnel  termed 
supply  catalogers.  These  supply  cata logers  have  separate  and 
distinct  functions  relating  to  outgoing  and  incoming  SSRs. 

For  outgoing  SSRs,  this  branch  performs  catalog 
data  screening,  reviews  the  screening  results  and  annotates  the 
results  on  provisioning  forms.  This  branch  takes  several  actions 
on  new  items  including  assigning  Activity  Control  Numbers  (ACNs), 
IMC,  standard  item  name,  and  FSC.  The  supply  cataloger  also 
assigns  one  or  more  PCCs  to  each  provisioning  package.  The  ini¬ 
tial  split  out  of  retained  items,  NIMSR  candidates  and  SSR  can¬ 
didates  takes  place  in  this  branch.  This  branch  is  responsible 
for  keypunching  manually  generated  SSR  and  advice  transactions 
and  mailing  them  to  the  appropriate  IMM.  A  manual  control  file 
is  maintained  to  serve  as  a  record  of  SSR  transactions  submitted 
until  they  are  complete.  This  branch  monitors  updating  of  the 
automated  SSR  Suspense  File  with  advice  transactions,  Offer  Reply 
transactions  and  manually  generated  provisioning  SSR  transac¬ 
tions.  The  supply  cataloger  initiates  update  of  the  local  ICP 
files  when  NSN  notifications  are  receive. d  and  maintains  history 
records  of  all  SSR  transactions  completed  within  the  last  two 
years  . 


299 


\ 


V 


i 


The  functions  performed  for  incoming  SSR  trans¬ 
actions  by  the  supply  cataloger  differ  significantly.  For  incom¬ 
ing  SSR  transactions,  the  supply  cataloger  is  responsible  for 
validating  incoming  transactions  and  processing  all  followup 
transactions  received.  He  performs  catalog  data  screening  and, 
based  on  the  results  of  this  screening,  determines  the  advice  to 
be  returned  to  the  SICC.  He  prepares  and  mails  advice  and  Follow¬ 
up  Response  transactions  to  the  SICC,  and  maintains  a  history 
file  of  SSR  transactions  received  and  processed.  He  notifies 
the  Cataloging  Division  of  items  accepted  for  support  and  gener¬ 
ates  Planned  Program  Requirements  (PPR)  cards  to  lodge  SSR  quan¬ 
tities  in  requirements  records. 

( 2 )  Cataloging  Branch 

The  Cataloging  Branch  is  involved  in  assigning 
various  elements  of  cataloging  data  during  the  provisioning  effort 
Some  of  these  data  elements  include  the  Submitting  Activity  Code, 
tho  Managing  Activity  Code  and  the  Shelf  Life  Code. 

Incoming  SSR  processing  is  primarily  keyed  toward 
fulfilling  specified  catalog  actions;  e.g.,  Add  User  actions.  How 
ever,  when  file  discrepancies  are  found  by  the  IEB  during  catalog 
data  screening,  this  branch  is  responsible  for  resolving  these 
conflicts  to  make  the  files  compatible. 

(3)  Packaging  Branch.  This  branch  is  responsible 
for  assigning  packing  and  preservation  data  for  items  retained 
for  management  by  SPCC. 

(4)  Data  Services  Branch  (DSB).  The  DSB  consists 
of  equipment  specialists  responsible  for  processing  Item  Control 
Recommendations  (ICRs)  received  from  field  maintenance  personnel. 
Items  on  these  ICRs  may  be  retained  for  management,  or  they  may 
result  in  nonprovisioning  SSR  transactions.  The  ICRs  submitted 
are  reviewed  for  adequacy  of  technical  data  and  validity  of  data 
elements  entered.  This  branch  initiates  catalog  data  screening 
for  these  items  and  assigns  IMC  and  FSC  for  new  items.  SSR 
transactions  are  formatted  by  the  branch  and  forwarded  to  the 
IEB  for  keypunching  and  transmittal.  This  branch  maintains  a 
control  file  of  active  ICRs  and  a  history  file  of  those  completed. 
The  ICR  originator  is  notified  by  this  branch  of  the  NSN  assigned 
each  item. 

2.  Management  Operations  Division.  The  Management  Analysis 
Branch  (MAB)  within  this  division  is  responsible  for  quality 
review  of  all  inputs  to  the  provisioning  subsystems.  It  also 
monitors  all  projects  input  to  the  automated  provisioning  sub¬ 
systems  until  all  items  in  the  project  pass  validation. 
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3.  Central  Data  Processing  Division  (CDPD).  This  division 
provides  keypunch  support  and  monitors  automated  inputs  and  pro¬ 
cessing  cycles.  This  division  also  performs  EAM  processing  for 
incoming  SSR  transactions. 

D.  OUTGOING  PROVISIONING  SSR  GENERATION  AND  PROCESSING 


There  are  five  distinct  operational  provisioning  systems  at 
SPCC  which  may  result  in  generation  of  outgoing  SSR  transactions. 
Two  of  these  systems  are  semiautomated .  The  remaining  three  are 
totally  manual  and  provide  for  provisioning  of  nuclear  equipments, 
strategic  systems  and  the  Trident  submarine.  Each  of  these  manual 
systems  employs  its  own  method  of  provisioning  and  SSR  transac¬ 
tions  are  generated  and  processed  on  a  totally  manual  basis.  The 
two  semiautomated  systems  are  those  used  within  the  Weapons  Sys¬ 
tems  Support  Group  for  provisioning  HME&O  Equipments  and  Electron¬ 
ics  Equipments.  The  vast  majority  of  SSR  transactions  generated 
and  processed  come  through  these  semiautomated  systems.  The  opera¬ 
tional  review  was  limited  to  only  these  semiautomated  systems 
because  SSR  transaction  processing  is  identical  between  them, 
although  the  generation  through  provisioning  processing  differs. 
Only  the  HME&O  operational  system  was  reviewed  in  detail  and  is 
presented  here . 

The  Navy  Outgoing  HME&O  Provisioning  SSR  Operational  System 
is  shown  in  Figure  III-3.  This  operational  system  begins  at  the 
time  the  PTD  is  submitted  by  the  contractor  and  continues  through 
the  time  notification  of  final  acceptance  is  received  from  the 
IMMs.  This  figure  illustrates  the  sequence  of  major  events  within 
each  of  the  processing  phases  in  this  operational  system.  The 
discussion  of  this  system  is  based  on  specific  subevents  occurring 
in  each  of  the  major  events  shown.  The  relationships  between 
these  subevents  and  phases,  and  the  organisational  elements  per¬ 
forming  them  is  shown  by  the  Navy  Outgoing  HME&O  Provisioning 
SSR  Work  Flow  Chart  (Figure  III-4). 

There  are  no  processing  priorities  for  items  processed  in 
this  system.  The  system  generates  intraservice  as  well  as  inter¬ 
service  SSR  transactions  in  the  standard  SSR  format.  External 
and  internal  followups  are  not  generated  within  this  system  and 
the  system  is  not  designed  to  generate  SSR  change  transactions 
on  an  automated  basis.  Generally,  when  a  DCN  is  received  from  a 
contractor,  it  is  processed  in  one  of  two  ways.  When  the  provi¬ 
sioning  project  has  not  reached  the  automated  stage  of  processing, 
the  DCN  is  combined  with  and  processed  as  part  of  the  provision¬ 
ing  project;  otherwise,  the  DCN  results  In  manual  preparaton  of 
direct  file  update  transactions  and  SSR  transactions.  A  DCN 
only  has  impact  on  an  SSR  item  when  it  indicates  a  new  item  or  a 
significant  increase  in  quantities  for  an  existing  item.  When  a 
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DON  requires  preparation  of  SSR  transactions,  only  initial  sub¬ 
mittals  are  used,  the  Type  Change  Codes  in  the  IMM  Manual  are  not 
used  . 

1.  Contractor  Processing  Phase.  This  processing  phase  con¬ 
sists  of  a  single  major  event  as  shown  in  Figure  III-3.  Gener¬ 
ally,  it  is  not  a  contractual  requirement  in  provisioning  HME&O 
Equipments  for  the  contractor  to  perform  DLSC  Screening. 

a.  Prepare  PTD.  This  major  event  consists  of  a  single 
subevent  as  shown  in  Figure  III-4. 

(1)  Provisioning  Technical  Documentation  (PTD)  is 
prepared  by  the  contractor  and  submitted  by  mail  to  SPCC.  The 
documentation  is  received  in  the  Clerical  Screening  and  Distribu 
tion  Section  (CSDS)  and  is  generally  in  hard  copy  form. 

2.  Provisioning  Processing  Phase.  This  processing  phase  is 
made  up  of  six  major  events:  File  Establishment,  Catalog  Data 
Screening,  IMC ,  SM&R,  Requirements  Determination  and  File  Estab- 
1 i shmen  t . 

a.  File  Establishment.  This  major  event  consists  of 
the  seven  subevents  shown  in  Figure  1 1 1-4  and  re suits  in  placing 
the  provisioning  project  in  the  SPCC  Provisioning  Monitoring 
Application  and  establishing  the  item  on  the  Weapon  Systems  File 
( WSF)  . 

(1)  The  PTD  is  received  from  the  contractor  in  hard 
copy  form  by  the  CSDS.  The  CSDS  reviews  the  PTD  for  adequacy. 

(2)  After  the  review,  a  manual  project  folder  is 
established  and  a  Provisioning  Document  Control  Number  (PDCN)  is 
assigned.  This  project  folder  serves  as  a  provisioning  project 
file  throughout  the  provisioning  process. 

(3)  The  CSDS  initiates  the  Provisioning  File  Load 
(Monitoring  and  Program  Data)  Torm.  This  form  is  partially 
completed  and  forwarded  to  the  Central  Data  Processing  Division 
(CDPD)  where  the  data  is  keypunched  and  entered  into  the  next 
cycle  of  the  U1CP  Provisioning  Monitoring  Application.  This 
application  enters  the  project  on  the  Provisioning  Monitoring 
File  (PMF)  which  serves  as  the  only  control/suspense  file  until 
the  major  UICP  files  (WSF,  local  TIR,  PSI,  TRF ,  ONR )  are  loaded. 
This  application  provides  a  series  of  prepunched  update  cards 
which  are  entered  subsequent  to  completion  of  processing  by  spe¬ 
cific  organizational  elements.  The  update  cards  and  form  are 
returned  to  the  CSDS  and  placed  in  the  project  folder. 


(4)  When  the  project  has  been  established  on  the 
PMF,  the  project  folder  is  forwarded  to  the  provisioner.  The 
provisioner  for  HM&E  Equipments  is  within  the  Ships  Division, 
while  the  provisioner  for  Ordnance  Equipment  is  in  the  Ordnance 
Division;  Figure  III-4  applies  to  the  Ships  Division.  Processing 
actions  in  the  two  Divisions  are  similar.  Upon  transfer  of  the 
project  folder  to  the  provisioner,  the  CSDS  forwards  an  update 
card  to  CDPD  for  PMF  file  updating. 

(5)  The  provisioner  reviews  the  PTD  for  adequacy. 

When  determined  to  be  inadequate,  the  provisioner  prepares  a 
letter  to  the  contractor  citing  the  specific  additional  data 
required  to  process  the  provisioning  project.  The  project  folder 
and  letter  citing  deficiencies  are  returned  to  CSDS  for  mailing. 

When  the  additional  data  required  is  received  from  the  contrac¬ 
tor,  it  is  placed  in  the  project  folder  and  returned  to  the  pro¬ 
visioner  for  processing. 

When  the  project  data  is  adequate,  the  Provi¬ 
sioning  File  Load  (Monitoring  and  Program  Data)  Form  has  the 
required  data  added  to  establish  the  equipment  on  the  WSF.  The 
form  is  forwarded  to  CDPD  through  CSDS  for  a  direct  file  update 
of  the  WSF.  The  form  is  returned  to  the  provisioner  when  the 
data  is  input  to  the  file  update  application. 

(6)  The  Provisioning  File  Load  (Monitoring  and  Pro¬ 
gram  Data)  Form  is  completed  by  the  provisioner  by  entering  appli¬ 
cable  program  data  not  already  on  the  form.  The  provisioner  then 
makes  the  range  and  depth  determinations  from  the  PTD  submitted. 

For  each  item  selected  for  support  a  Provisioning  File  Load  (Item 
Data)  Form  is  initiated. 

(7)  All  forms  are  placed  in  the  project  folder  which 
is  forwarded  to  the  Item  Entry  Branch  (IEB)  for  further  processing. 
An  update  card  is  forwarded  to  the  CDPD  for  PMF  update  at  this  time. 

b.  Catalog  Data  Screening.  This  major  event  consists  of 
three  subevents  and  includes  both  DLSC  screening  and  local  file 
screening . 

(1)  The  Item  Entry  Branch  initiates  a  screening  trans¬ 
action  for  each  item  in  the  provisioning  project  which  was  entered 
on  a  Provisioning  File  Load  (Item  Data)  Form.  These  screening 
transactions  are  entered  into  the  UICP  Provisioning  Screening  Appli¬ 
cation  by  CDPD.  (This  application  was  discussed  in  Part  1  of  this 
Volume.)  The  items  are  screened  against  DLSC  files  and  local  files 
with  results  printed  out  for  use  by  the  IEB. 

(2)  The  screening  results  are  reviewed  by  the  IEB  and 
split  into  two  groups.  One  group  consists  of  items  which  matched 
to  one  or  more  NSNs ;  the  other  group  consists  of  part  numbers  which 
did  not  match  to  an  existing  NSN. 
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(3)  For  items  which  matched  to  an  existing  NSN,  the 
Provisioning  File  Load  (Item  Data)  Forms  are  annotated  with  the 
NIIN,  FSC,  IMC  and  other  appropriate  data.  The  part  number  items 
are  assigned  an  ACN  which  is  annotated  on  the  forms. 

c.  IMC .  This  major  event  consists  of  four  subevents  and 
results  in  IMC  coding  of  the  part  number  items  and  determination 
of  SSR  candidate  items. 

(1)  The  screening  results  and  PTD  submitted  for  part 
number  items  are  reviewed  by  the  IEB  and  an  IMC  is  assigned  for 
each  item.  The  IMC  is  annotated  on  the  Provisioning  File  Load 

( Item  Data)  Form. 

(2)  Based  on  the  IMC  assigned  and  other  item  data 
the  IEB  assigns  an  item  name,  FSC  and  PCC,  and  enters  these  on 
the  form. 

(3)  All  support  items  are  then  reviewed  and  fall  into 
three  categories:  Items  retained  by  SPCC  for  management,  noncon¬ 
sumable  items  managed  by  other  Service  ICPs  or  ASO ,  and  require 
initiation  of  a  NIMSR,  and  consumable  items  managed  by  DLA,  GSA 
and  other  Services.  This  last  category  is  tested  against  the 
criteria  contained  in  Figure  III-5.  Those  HME&O  items  meeting  the 
criteria  for  SSR  generation  are  coded  on  the  Item  Data  Form  for 
generation  of  SSR  candidate  transactions.  Those  not  meeting  these 
criteria  are  coded  to  bypass  SSR  candidate  generation. 

SPCC  SSR  CANDIDATE  CRITERIA  FOR  HME&O  ITEMS 

1.  An  SSR  Candidate  will  be  generated  when  an  item  meets  one  of 
the  following  conditions: 

a.  The  item  is  a  new  supply  support  type  item  for  which  DLSC 
screening  shows  no  record. 

b.  The  item  is  an  existing  supply  support  type  NIIN  for  which 
DLSC  screening  does  not  show  SPCC  as  a  user. 

c.  The  item  is  a  supply  support  item  (new  or  established) 
having  TRIDENT  application. 

2.  When  DLSC  screening  shows  SPCC  as  a  manager  or  as  a  user  of  an 
established  NIIN,  an  SSR  Candidate  will  not  be  generated. 

Source:  SPCC  Internal  Instruction  4A00.30C  of  31  August  1977, 

pages  IIIA3  and  IIB158. 

Figure  III-5 
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(4)  The  IEB  places  all  forms,  PTD  and  screening 
results  In  the  project  folder  and  forwards  it  to  the  provi- 
sloner.  A  PMF  update  card  is  forwarded  to  the  CDPD  to  update 
the  project  to  show  completion  of  IEB  processing. 

d.  SM&  R .  There  are  two  subevents  in  this  major  event. 

(1)  The  provisioner  reviews  the  PTD  submitted  by 
the  contractor,  the  catalog  data  screening  results  and  the 
Provisioning  File  Load  (Item  Data)  Forms.  From  this  data  the 
SM&R  codes  are  assigned  and  entered  on  the  Provisioning  File 
Load  (Items  Data)  Form. 

(2)  All  other  required  technical  data  not  already 
assigned  is  determined  at  this  time  and  entered  on  the  Provi¬ 
sioning  File  Load  (Item  Data)  Form  for  each  item. 

e.  Requirements  Determination.  This  major  event  con¬ 
sists  of  three  subevents  as  shown  in  Figure  III-4. 

(1)  When  requirements  are  computed  manually,  the 
computation  is  performed  at  this  point  in  the  processing  by  the 
provisioner. 

(2)  The  computed  requirements  are  annotated  on  the 
Provisioning  File  Load  (Item  Data)  Form  for  each  item  and  each 
form  is  coded  to  bypass  automated  computations. 

(3)  All  forms,  screening  results,  and  PTD  are  placed 
in  the  project  folder  and  forwarded  to  the  Cataloging  Branch. 

An  update  card  is  forwarded  to  the  CDPD  to  update  the  PMF  showing 
this  processing  step  has  been  completed. 

f.  File  Establishment.  There  are  eight  subevents  within 
this  major  event.  In  this  event  the  Provisioning  File  Load  Forms 
are  completed  and  items  are  established  on  the  major  ICP  files. 

(1)  The  cataloger  assigns  and  codes  cataloging  data 
on  both  the  Provisioning  File  Load  (Monitoring  and  Program  Data) 
Form  and  the  Provisioning  File  Load  (Item  Data)  Forms.  For  SSR 
candidates  this  data  consists  of  entering  the  submitting  and  manag¬ 
ing  activities.  For  other  items  other  cataloging  data  is  also 
entered,  e.g.,  shelf  life.  The  cataloger  also  establishes  one 

or  more  PCC  folders  which  then  become  part  of  the  project  folder. 

(2)  Items  retained  for  management  are  passed  to  the 
packaging  branch,  while  other  items  are  temporarily  filed  in  the 
IEB. 

(3)  Preservation  and  packaging  data  is  assigned  by 
the  Packaging  Branch.  When  this  data  is  entered  on  the  forms, 
they  are  forwarded  to  the  IEB. 
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(4)  The  IEB  pulls  the  project  f  uder  from  the  tem¬ 
porary  file  and  adds  items  forwarded  by  the  lackaging  Branch. 

The  Provisioning  File  Load  Forms  are  extracted  from  the  project 
folder  and  forwarded  to  the  Management  Analysis  Branch  (MAB). 

(5)  The  MAB  performs  a  quality  review  of  the  forms. 
Forms  in  error  are  returned  to  the  IEB  for  correction. 

(6)  When  the  forms  in  error  are  returned  to  the  MAB 
or  the  quality  review  indicates  no  errors,  the  forms  are  forwarded 
to  the  CDPD.  An  update  card  accompanies  the  forms  to  CDPD  to  up¬ 
date  the  PMF  to  reflect  completion  of  the  quality  review  for  the 
project. 

(7)  CDPD  receives  the  forms  and  keypunches  them  for 
input  to  the  HME&O  provisioning  subsystem.  The  forms  are  returned 
to  MAB  after  validation  by  the  HME&O  provisioning  subsystem.  Vali¬ 
dation  outputs  shown  on  Figure  III-l  are  forwarded  to  MAB  where 
they  are  reviewed.  Items  containing  data  in  error  are  recoded  with 
the  proper  information  and  returned  to  CDPD  for  keypunch  and  input 
to  the  HME&O  Provisioning  Subsystem.  When  all  items  for  a  project 
appear  on  the  Cleared  Items  List  (meaning  all  items  in  the  project 
have  passed  validation),  the  MAB  returns  the  Provisioning  File 
Load  Forms  to  the  IEB  and  forwards  the  final  update  card  to  CDPD 

to  update  the  PMF  showing  all  monitored  actions  complete. 

(8)  When  all  items  in  a  provisioning  project  clear 
validation,  the  HME&O  Provisioning  Subsystem  generates  transac¬ 
tions  to  establish  these  items  on  appropriate  ICP  files  and  passes 
item  transactions  to  the  UICP  Wholesale  Requirements  Computation 
Applicat ion . 

g.  Requirements  Determination.  This  major  event  con¬ 
sists  of  two  subevents;  automated  requirements  computations  and 
generation  of  SSR  candidate  transactions. 

(1)  When  requirements  computations  are  performed 
manually  as  described  above,  this  subevent  is  bypassed.  Computa¬ 
tion  of  the  retail  and  replenishment  quantities  for  SSR  transac¬ 
tions  are  computed  by  the  HME&O  Provisioning  Subsystem  as  are  the 
retail  requirements  for  retained  items.  The  wholesale  require¬ 
ments  for  retained  items  are  computed  in  the  UICP  Wholesale 
Requirements  Computation  Application. 

(2)  Subsequent  to  computation  of  requirements,  SSR 
candidate  transactions  are  generated  and  passed  to  the  UICP  SSR 
Application. 

3.  SICC  SSR  Processing  Phase.  This  processing  phase  con¬ 
sists  of  two  major  events.  Processing  up  to  this  point  has  been 
on  a  project  or  provisioning  package  basis.  At  this  point  pro¬ 
cessing  continues  on  an  item  basis. 


1 

a.  Edit/Validation.  This  major  event  consists  of  two  ! 

subevents  to  validate  SSR  candidates  on  an  automated  basis. 

(1)  Outgoing  provisioning  SSR  candidates  are  input 
to  the  UICP  SSR  Application. 

(2)  SSR  candidates  undergo  extensive  validation. 

Transactions  in  error  must  be  manually  recorded,  keypunched  and 
input.  Valid  transactions  continue  processing. 

b.  File  Maintenance.  This  major  event  consists  of  four 
subevents  to  update  the  SSR  Suspense  File  and  generate  outgoing 
SSR  transactions. 

(1)  After  validation,  transactions  update  the  auto¬ 
mated  SSR  Suspense  File. 

(2)  SSR  transactions  are  punched  out  and  listings 
for  functional  use  are  printed.  The  cards  and  lists  are  for¬ 
warded  to  the  IEB. 

(3)  The  IEB  combines  the  technical  data  for  part 
number  items  with  the  SSR  transactions  and  pulls  the  Item  Name 
transactions  out  for  these  items.  These  Item  Name  transactions 
are  disposed  of  and  the  SSR  transactions  and  technical  data  are 
mailed  to  the  appropriate  IMMs. 

(4)  The  listings  are  filed  in  the  PCC  folder  for 
use  as  a  control  file  of  items  submitted. 

4.  IMM  SSR  Processing  Phase.  This  processing  phase  is  ac¬ 
complished  by  IMMs  and  results  in  the  return  of  advice  transac¬ 
tions  (accept,  offer,  reject,  NSN  no t if i ca t ions  )  as  shown  in 
Figure  III-3. 

5.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
consists  of  the  three  major  events  shown  in  Figure  III-3  which 
complete  the  SSR  processing  cycle. 

a.  File  Maintenance.  This  major  event  consists  of  the 
three  subevents  shown  in  Figure  III-4. 

(1)  Advice  transactions  are  received  from  the  IMMs 

by  the  IEB. 

(2)  The  PCC  folder  is  pulled  from  the  control  file. 

(3)  The  advice  from  the  transaction  is  annotated  on 
the  SSR  Valid  Transaction  List  for  each  item. 

b.  Advice  Review.  Each  category  of  advice  is  shown  as 
a  separate  subevent  on  Figure  III-4  for  discussion. 
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(1)  Accept  Advice  transactions  are  duplicated,  with 
one  card  filed  in  the  P CC  folder  with  the  SSR  Valid  Transaction 
List  and  the  second  forwarded  to  CDPD  for  input  to  the  UICP  SSR 
Application  to  update  the  SSR  Suspense  File. 

(2)  Offer  Advice  transactions  and  accompanying  tech¬ 
nical  data  are  forwarded  to  the  provisioner  for  offer  accept/offer 
reject  decision.  The  decision  is  translated  into  an  Offer  Reply 
transaction  by  the  IEB.  The  Offer  Reply  transaction  is  duplicated, 
with  one  card  mailed  to  the  IMM  and  the  other  forwarded  to  CDPD 

to  update  the  SSR  Suspense  File. 

(3)  Reject  Ad vi ce  transactions  are  reviewed  to  deter¬ 
mine  the  data  in  error.  The  IEB  obtains  the  proper  data  from 

the  appropriate  branch  (provisioning,  cataloging,  etc.)  and  for¬ 
mats  new  SSR  transactions.  These  coded  transactions  are  forwarded 
to  CDPD  where  they  are  keypunched  and  reentered  in  the  UICP  SSR 
Application.  The  resulting  transactions  are  submitted  by  mail  to 
the  appropriate  IMM  by  the  IEB. 

(4)  NSN  Notifications  are  reviewed  in  the  IEB  with 
the  assigned  NSN  annotated  on  the  SSR  Valid  Transaction  List. 

Action  is  taken  by  the  IEB  to  update  ICP  files  with  the  assigned 
NSN. 


c.  File  Maintenance.  This  major  event  consists  of  the 
single  subevent  shown  in  Figure  III-4. 

(1)  When  an  SSR  Valid  Transaction  List  is  complete 
it  is  transferred  to  a  PCC  History  File  and  retained  for  two 
years  . 

E  .  OUTGOING  NONPROVISIONING  SSR  GENERATION  AND  PROCESSING 

Nonprovisioning  SSRs  usually  emanate  from  two  sources  at 
SPCC.  One  source  is  the  ACN  File  generated  in  the  UICP  SPCC 
P r o v i s i on i ng / SSR  Interface  Application.  These  items  become  non¬ 
provisioning  SSR  candidates  when  routine  DLSC  screening  indicates 
a  match,  three  demands  for  the  item  occur  within  six  months,  the 
item  becomes  an  allowed  on-board  item,  or  the  item  surfaces  during 
a  reprovisioning  or  recomputation  effort.  These  items  are  coded 
on  Provisioning  File  Load  Forms  and  processed  by  the  same  orga¬ 
nizational  elements  as  provisioning  SSRs. 

The  second  source  is  Item  Control  Recommendations  (ICRs) 
submitted  by  field  maintenance  personnel.  These  ICRs  are  sub¬ 
mitted  to  SPCC  as  part  numbered  items  requesting  NSN  assignment. 
These  ICRs  constitute  the  majority  of  non p r o v i s i oni ng  SSRs  gener¬ 
ated  and  the  discussion  that  follows  is  keyed  to  their  processing. 
The  Outgoing  Nonprovisioning  SSR  Operational  System  is  displayed 
in  Figure  III-6.  As  shown  in  this  figure,  the  operational  system 
consists  of  four  phases  made  up  one  or  more  major  events.  There 
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Figure  III- 


is  no  specific  order  or  priority  of  processing  and  no  followup 
or  Offer  Reply  transactions  are  generated  in  this  system.  The 
Outgoiong  Nonprovisioning  SSR  Work  Flow  Chart  (Figure  III-7) 
relates  subevents  and  organizational  elements  to  major  events 
and  processing  phases. 

1.  Nonprovisioning  Processing  Phase.  This  processing  phase 
consists  of  two  major  events  as  shown  in  Figure  III-6  to  screen 
each  item  submitted  and  to  IMC  each  new  item. 

a.  Catalog  Data  Screening.  There  are  six  subevents 
included  in  this  major  event. 

(1)  Item  Control  Recommendations  are  received  in 
the  Data  Services  Branch  (DSB). 

(2)  Each  ICR  is  reviewed  to  ensure  the  technical 
data  submitted  is  adequate  or  that  an  appropriate  MIL-STD  or 
MIL-SPEC  is  referenced.  The  ICR  itself  is  checked  for  valid 
entries  in  estimated  annual  usage,  unit  cost,  unit  of  issue  and 
descriptive  data  areas.  When  invalid  entries  are  found  or  data 
is  incomplete,  the  ICR  is  returned  to  the  originating  activity 
as  a  reject. 


(3)  Those  ICRs  found  to  be  valid  and  accompanied  by 
adequate  technical  data  undergo  catalog  data  screening.  The 
screening  request  transactions  are  formatted  by  the  DSB. 

(4)  The  IEB  keypunches  the  screening  request  trans¬ 
actions  and  forwards  them  to  CDPD  for  input  to  the  UICP  Provi¬ 
sioning  Screening  Application. 

(5)  The  UICP  Provisioning  Screening  Application  pro¬ 
cesses  the  screening  requests  and  forwards  them  to  DLSC.  Returns 
from  DLSC  are  processed,  with  NSNs  returned  being  screened  against 
local  ICP  files.  Results  of  the  screening  are  returned  to  the 
IEB  who  forwards  the  printouts  to  the  DSB. 

(6)  The  DSB  reviews  the  screening  results  and  takes 
action  on  each  item. 

(a)  When  the  screening  result  indicates  an  exact 
match  to  an  NSN,  and  the  Navy  is  shown  as  the  manager  of  the  item 
or  as  a  registered  user  of  the  item,  the  ICR  is  annotated  with  the 
NSN  and  returned  to  the  originator  (no  SSR  is  sent). 

(b)  When  the  screening  result  indicates  an  exact 
match  to  an  NSN,  and  the  Navy  is  not  shown  as  manager  or  recorded 
as  a  user,  the  item  becomes  an  SSR  candidate. 
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(c)  On  possible  match  screening  results  a 
letter  is  prepared  by  the  DSB  to  the  originating  activity  request¬ 
ing  review  and  advice  as  to  the  acceptability  of  these  matched 
items.  When  a  possible  match  is  accepted  by  the  originator,  the 
item  is  processed  identical  to  the  exact  matches  described  above. 
When  the  originator  rejects  the  possible  matches,  the  original 
part  number  is  processed  as  described  below. 

b.  IMC .  The  major  event  consists  of  two  subevents. 

(1)  Items  which  were  returned  from  DLSC  with  a  no 
match  condition  and  possible  matches  rejected  by  the  ICR  origi¬ 
nator  require  IMC. 

(2)  Each  of  these  items  are  reviewed  in  conjunction 
with  available  technical  data  and  an  IMC  and  FSC  is  assigned. 

These  items  generally  fall  into  two  groups;  retained  items  and 
SSR  candidates. 

2.  SICC  SSR  Processing  Phase.  This  processing  phase  con¬ 
sists  of  a  single  major  event  and  results  in  SSR  transactions 
and  associated  technical  data  being  mailed  to  the  appropriate 
IMM. 

a.  File  Maintenance.  This  major  event  consists  of 
three  subevents. 

(1)  SSR  transactions  are  formatted  for  the  SSR  can¬ 
didates  identified  in  the  previous  processing  phase.  The  coded 
SSR  transactions  are  forwarded  to  the  IEB  with  the  accompanying 
technical  data  for  part  numbered  items. 

(2)  SSR  transactions  are  manually  keypunched,  com¬ 
bined  with  the  technical  data  and  mailed  to  the  appropriate  IMM 
by  the  IEB. 

(3)  When  the  SSR  transactions  are  passed  to  the 
IEB,  the  ICR  is  placed  in  a  control  file  to  await  advice 

the  IMM. 

3.  IMM  SSR  Processing  Phase.  This  processing  phase  is  per¬ 
formed  by  IMMs  and  results  in  the  return  of  advice  transactions 
to  SPCC . 

k.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
consists  of  three  major  events  to  process  advice  transactions 
returned  by  the  IMM. 
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a.  Advice  Review.  When  advice  is  received  from  IMMs  in 
the  DSB,  it  is  categorized  as  accept,  reject,  offer  or  NSN  noti¬ 
fication  advice.  Each  category  is  discussed  as  a  separate  sub¬ 
event  . 

(1)  Accept  Advice  is  reviewed  to  determine  if  an 
NSN  is  included  on  the  advice  transaction.  If  not,  the  advice 
transaction  is  filed  in  the  control  file  with  the  ICR. 

( 2 )  Reject  Advice  is  reviewed  to  determine  the 
error.  When  the  correct  data  is  identified  new  SSR  transactions 
are  coded  and  forwarded  to  the  IEB  for  keypunching  and  mailing 
tc  the  I  MM. 

(3)  Offer  Advice  transactions  are  mailed  to  the  ICR 
originator  for  acce p t / re j ec t  decision.  When  the  decision  is 
returned  to  the  DSB,  new  SSR  transactions  are  coded  containing 
the  offered  item  if  the  decision  is  accept  or  the  original  item 
if  the  decision  is  reject.  These  coded  SSR  transactions  are 
forwarded  to  the  IEB  for  keypunching  and  mailing  to  the  IMM. 

(4)  NSN  Notification  transactions  are  matched  to 
the  ICR  in  the  control  file. 

b.  File  Maintenance-  This  major  event  consists  of  two 
subevents  . 

(1)  When  accept  advice  is  received  for  an  item  having 
an  NSN  or  when  the  NSN  notification  is  received  for  a  part  num¬ 
bered  item,  the  ICR  and  associated  information  is  extracted  from 
the  control  file. 

(2)  The  original  ICR  is  held  for  return  to  the  orig¬ 
inator  and  the  remainder  of  the  information  including  a  copy  of 
the  ICR,  all  related  correspondence,  advice  cards  received  and 
coded  SSR  transactions  are  retained  in  a  history  file  for  three 
years  in  PCC ,  ISN  sequence. 

c.  Notification  Actions.  This  major  event  consists  of 
two  subevents  to  notify  the  ICR  originator  of  the  NSN  assigned 
to  the  requested  item. 

(1)  The  DSB  annotates  the  assigned  NSN  on  the  ICR 
before  filing  the  advice  transaction  in  the  history  file. 

(2)  The  DSB  mails  the  annotated  ICR  to  the  origina¬ 
tor  to  provide  him  with  the  NSN  assigned  to  the  requested  item. 
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NAVY  INCOMING  SSR  PROCESSING 


The  operational  system  used  at  SPCC  for  processing  incoming 
SSR  transactions  is  illustrated  in  Figure  III-8.  As  shown  by 
the  figure,  processing  is  centered  around  the  IMM  SSR  Processing 
Phase.  Processing  in  this  operational  system  is  primarily  manual, 
with  no  distinction  made  between  provisioning  and  nonprovisioning 
SSR  transactions.  There  is  no  set  procedure  for  processing  SSR 
change  transactions  and  the  discussion  that  follows  does  not  in¬ 
clude  these  transactions.  In  addition,  only  SSR  transactions 
containing  an  NSN  or  SSR  transactions  for  crypto  security  items 
are  processed  by  SPCC;  all  others  are  routinely  rejected.  The 
number  of  SSR  transactions  received  for  crypto  security  items  is 
sufficiently  small  to  omit  discussion  of  the  processing  of  these 
transactions.  Therefore,  the  operational  system  shown  is  keyed 
to  processing  of  initial  submission  SSR  transactions  containing 
an  NSN. 

Figure  III-8,  illustrates  the  submittal  of  SSR  transactions 

and  followup  transactions  by  SICCs  to  SPCC  as  the  IMM . en 

these  transactions  arrive  at  SPCC  the  followup  transactions  are 
separated  from  the  SSR  transactions.  Followup  transactions  are 
processed  immediately  upon  receipt.  The  SSR  transactions  are 
placed  in  a  hold  status  for  processing  on  a  ten-day  to  two-week 
cycle  depending  on  volume.  SPCC  does  not  generate  offer  advice 
transactions  as  reflected  in  the  operational  system  (Figure 
III-8)  . 

1.  SICC  SSR  Processing  Phase.  This  processing  phase  occurs 
at  the  provisioning  activity  and  results  in  submittal  of  SSR  and 
followup  transactions  to  SPCC  as  a  WIMM. 

2.  IMM  SSR  Processing  Phase.  This  processing  phase  consists 
of  eight  major  events  as  shown  in  Figure  III-8.  These  major 
events  include  Edit /Validation ,  Advice  Decision,  File  Maintenance, 
Catalog  Data  Screening,  Advice  Decision,  File  Maintenance,  Cata¬ 
log  Actions,  and  Requirements  Determination.  Incoming  SSR  trans¬ 
actions  do  not  play  a  part  in  Method/Level  of  Support  decisions, 
and  thus,  this  major  event  from  the  conceptual  system  is  not 
present.  Although  the  operational  system  chart  shows  all  of  these 
major  events  occuring  within  the  IMM  Processing  Phase,  it  does  not 
indicate  the  repetitive  nature  of  the  occurrence  of  many  of  these 
major  events.  This  repetitive  nature  is  illustrated  by  the  WIMM 
NSN  SSR  Work  Flow  Chart  shown  as  Figure  III-9. 

a.  Edlt/Valldation.  This  major  event  consists  of  two 
subevents  as  shown  in  the  Navy  WIMM  NSN  SSR  Work  Flow  Chart 
(Figure  1 1 1-9  )  . 
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(1)  Incoming  SSR  transactions  and  followup  transac¬ 
tions  are  received  from  the  SICC  by  the  IEB.  The  transactions 
undergo  a  minimal  amount  of  validation.  When  an  error  is  de¬ 
tected,  the  SICC  is  contacted  via  telephone  to  determine  the 
correct  information.  This  information  is  keypunched  by  the  IEB 
into  an  SSR  transaction  to  replace  the  one  submitted  (control 
elements  are  not  altered). 

(2)  Followup  transactions  are  separated  from  the 
SSR  transactions  for  immediate  processing. 

b.  Advice  Decision.  This  major  event  consists  of  four 
subevents  to  determine  the  responses  to  submitted  followup  trans¬ 
actions. 


(1)  Followup  transactions  are  processed  by  matching 
them  to  the  Incoming  SSR  Hi  ,tory  File  on  ACF,  PCC,  DOR  and  ISN. 

(2)  When  matching  SSR  transactions  are  found  and  an 
advice  transaction  has  been  sent  to  the  SICC;  the  same  advice  is 
used  to  reply  to  the  followup.  When  matching  SSR  transactions 
are  not  found,  an  advice  of  no  record  is  used  to  reply  to  the 

f  o 1 lowup  . 

(3)  Followup  Response  transactions  are  generated 
from  the  data  in  the  followup  transactions,  adding  the  appropriate 
advice  and  a  Date  of  Advice  equal  to  the  current  date  plus  five 
days  . 


(4)  The  Followup  Response  transactions  are  mailed 
to  the  SICC  and  the  followup  transactions  and  a  duplicate  of  the 
Followup  Response  transaction  are  filed  in  the  history  file. 

c.  File  Maintenance.  This  major  event  consists  of  three 
subevents  to  initiate  processing  of  SSR  transactions. 

(1)  Every  ten  days  to  two  weeks  all  SSR  transactions 
received  are  forwarded  to  CDPD  for  EAM  processing.  This  begins 
the  SSR  processing  cycle  at  SPCC. 

(2)  EAM  processing  in  CDPD  consists  of  sorting  the 
SSR  transactions  into  ACF,  PCC,  DOR  and  ISN  sequence  and  pro¬ 
ducing  the  following  outputs. 

:  A  two-part  listing  of  the  transactions. 

:  Skeleton  advice  transactions. 

:  Skeleton  planned  program  requirement  (PPR) 

transactions. 
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These  outputs  are  returned  to  the  IEB  for  processing. 

(3)  The  IEB  places  the  original  SSR  transactions  in 
the  Incoming  SSR  History  File  and  uses  the  EAM  processing  outputs 
to  continue  processing  of  these  transactions.  This  is  the  only 
history  file  maintained  for  Incoming  SSR  transactions  and  is  in 
ACF,  PCC,  DOR,  and  ISN  sequence.  This  EAM  card  file  is  period¬ 
ically  purged  of  transactions  over  180  days  old. 

d.  Catalog  Data  Screening.  This  major  event  consists 
of  three  subevents  and  involves  screening  of  local  ICP  files. 

(1)  Each  SSR  item  appearing  on  the  SSR  transaction 
list  has  local  screening  transactions  prepared  by  the  IEB  and 
forwarded  to  CDPD  for  automated  screening  against  the  local  TIR 
file,  PSI  file,  TRF  and  ONR  file,  in  that  sequence,  until  a  match 
is  found.  When  a  match  is  found,  selected  data  is  extracted  and 
printed;  otherwise,  a  no  match  condition  message  is  printed.  The 
screening  results  are  returned  to  the  IEB. 

(2)  The  IEB  reviews  the  screening  results  to  ensure 
a  reply  was  received  for  each  item  submitted. 

(3)  Those  items  for  which  a  no  match  condition 
exists  are  separated  from  the  other  items. 

e.  Advice  Decision.  This  major  event  consists  of  three 
subevents  resulting  in  ini t ia 1 /f ina 1  advice  being  forwarded  to 
the  SICC. 

(1)  Items  which  did  not  match  to  local  files  are 
assigned  pending  advice  and  undergo  further  catalog  data  screen¬ 
ing  described  below.  Other  items  are  assigned  advice  using  SSR 
Filter  Chart  #1  (Figure  III-10).  As  indicated  by  the  SSR  Filter 
Chart,  items  which  were  found  in  the  TRF  or  ONR  file  and  items 
which  have  a  significant  Pending  Change  Notice  are  assigned 
pending  advice  and  undergo  further  screening  along  with  the  no 
match  items. 

(2)  The  skeleton  advice  transactions  generated  by 
EAM  processing  are  completed  by  adding  the  advice  from  the  SSR 
Filter  Chart  #1  and  a  Date  of  Advice  equal  to  the  current  date 
plus  five  days. 

(a)  Advice  transactions  containing  ATC  "36" 
were  rejected  because  the  item  requested  is  used  by  the  Navy  in 
nuclear  reactor  plant  application.  A  letter  stating  this  and 
suggesting  that  the  SICC  request  assignment  of  a  separate  NSN 
based  on  his  application  accompanies  each  advice  transaction 
containing  this  ATC. 


SPCC  WIMM  SSR  FILTER  CHART  #1 


Internal  Screening 


No 

* 

ATC  -  "YE" 

(support  accepted,  no  qualifications) 

Figure  III-10 
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(b)  The  advice  determined  is  annotated  beside 
each  item  on  the  SSR  transaction  list  and  those  items  assigned 
pending  advice  have  "Action  Pending"  written  in  the  margin  beside 
them. 


(3)  These  advice  transactions  are  mailed  to  the 
appropriate  SICC. 

f.  File  Maintenance.  This  major  event  consists  of  a 
single  subevent  to  update  the  SSR  History  File. 

(1)  A  duplicate  of  the  advice  transaction  is  placed 
with  the  original  SSR  transaction  in  the  Incoming  SSR  History 
File  . 


g.  Catalog  Actions.  This  major  event  consists  of  three 
subevents  to  complete  required  catalog  actions  on  SSR  items  that 
are  accepted  for  support. 

(1)  The  IEB  lines  out  those  items  on  the  SSR  Trans¬ 
action  List  that  were  rejected  for  support.  One  copy  of  the 
listing  is  forwarded  to  the  Cataloging  Branch.  • 

(2)  The  Cataloging  Branch  reviews  each  item  and 
initiates  required  catalog  transactions  (e.g.,  add  user  transac¬ 
tions)  to  update  DLSC  and  local  ICP  files. 

(3)  The  catalog  transactions  are  forwarded  to  CDPD 
for  automated  file  updating. 

h.  Requirements  Determination.  This  major  event  con¬ 
sists  of  two  subevents  to  ensure  SSR  requirements  are  included 
in  the  requirements  determination  process. 

(1)  The  IEB  divides  the  PPR  transactions  from  EAM 
processing  into  three  groups.  One  group  contains  transactions 
for  items  on  which  support  was  rejected;  these  transactions  are 
destroyed.  The  second  group  consists  of  transactions  for  items 
on  which  pending  advice  was  returned  to  the  SIC C;  these  transac¬ 
tions  remain  in  the  IEB.  The  last  group  is  for  items  on  which 
support  was  accepted;  these  transactions  are  completed  by  the 
IEB  . 


(2)  The  IEB  forwards  the  completed  PPR  transactions 
to  the  CDPD  for  processing.  The  CDPD  inputs  these  transactions 
for  automated  processing  which  places  the  SSR  requirements  in 
the  requirements  records  for  each  item  so  they  are  considered  in 
requirements  computation  and  forecasting. 

i.  Catalog  Data  Screening.  This  major  event  consists 
of  three  subevents  to  screen  items  for  which  a  pending  advice  was 
returned  to  the  SICC  against  DLSC  Files. 


331 


t 


V 


(1)  The  IEB  prepares  DLSC  screening  request  trans¬ 
actions  for  those  items  which  received  pending  advice  after  local 
file  screening  was  done.  The  screening  transactions  are  forwarded 
to  CDPD  for  input  to  the  UICP  Provisioning  Screening  Application 
discussed  in  subsection  D.  above.  Screening  results  are  returned 
to  the  IEB. 


(2)  The  IEB  reviews  the  screening  results  to  ensure 
responses  are  received  for  all  items. 

(3)  When  DLSC  screening  indicates  the  NSN  is  valid 
and  the  current  manager  is  SPCC,  the  item  is  set  aside  for  further 
action.  In  this  case,  a  discrepancy  between  DLSC  files  and  SPCC 
files  exists. 

j.  Advice  Decision.  This  major  event  consists  of  these 
subevents  as  shown  on  Figure  III-9. 

(1)  For  items  not  having  file  discrepancies  existing, 
existing,  an  advice  decision  is  reached  using  SSR  Filter  Chart  if  2 
(Figure  III-ll).  Note  that  all  of  the  advices  from  this  Filter 
Chart  are  rejects. 

(2)  Reject  Advice  transaction  \  are  generated  by  the 
IEB  using  the  ATCs  from  SSR  Filter  Chart  /•*  Those  advice  trans¬ 
actions  containing  ATC  "36"  have  the  scree  .ng  results  attached 
to  indicate  to  the  SICC  the  reason  for  th  ejection  of  support. 

A  Date  of  Advice  equal  to  the  currer  date  plus  five  days  is 
assigned  each  advice  transaction.  Pending  advice  transactions 
are  generated  for  items  having  file  discrepancies  to  be  resolved. 

(3)  The  advice  transactions  are  mailed  to  the  SICC. 

k.  File  Maintenance.  This  "lajor  event  consists  of  a 
single  subevent  to  update  the  Incoming  SSR  History  File. 

(1)  A  duplicate  of  the  advice  transaction  mailed  to 
the  SICC  is  filed  with  the  original  SSR  transactions  in  the  In¬ 
coming  SSR  History  File.  The  advice  is  annotated  beside  each 
item  on  the  SSR  transaction  list.  Those  items  not  receiving 
pending  advice,  received  rejected  advice  and  the  PPR  transactions 
for  these  items  are  destroyed. 

l.  Catalog  Actions.  This  major  event  consists  of  four 
subevents  to  resolve  file  discrepancies. 

(1)  The  IEB  forwards  items  on  which  file  discrepan¬ 
cies  exist,  along  with  DLSC  and  internal  file  screening  results 
to  the  Cataloging  Branch.  They  are  forwarded  under  cover  of  a 
memo  citing  a  10-day  suspense  for  completion  of  cataloging  action. 


332 


V 


SPCC  WIMM  SSR  FILTER  CHART  # 2 


DLSC  Screening 


.  Is  the  NSN  not  found? 


■  New  ATC  =  "YU" 
(support  rejected, 
NSN  not  in  DIDS) 


Is  the  NSN  cancelled  w/ o 
replacement  ? 


New  ATC  =  "YH" 

(support  rejected, 

NSN  cancelled  in  DIDS) 


Is  the  NSN  cancelled  with 
replacement? 


New  ATC  =  "YJ" 
(support  rejected  NSN 
replaced ) 


Is  there  a  change  pending? 


5.  Is  the  NSN  managed  by 
another  CIMM/WIMM 


Is  the  change 
significant?! 


Yes 

- * 

ATC  =  "68” 

(support  reject 
adverse  &NS) 


New  ATC  =  ” YK " 
(support  rejected, 
NSN  non-SPCC  ) 


ATC  -  ”36"  & 
attach  Screening  to  CXI 
(advice  unspecified, 
see  attached) 


Figure  III-ll 


(2)  The  Cataloging  Branch  reviews  each  item  to  deter¬ 
mine  the  discrepancies  and  the  cause  of  each. 

(3)  Action  is  taken  to  resolve  the  discrepancies  and 
take  other  necessary  cataloging  actions  through  the  use  of  file 
update  transactions.  These  transactions  are  forwarded  to  CDPD  for 
automated  file  update  processing,  resulting  in  compatible  DLSC 
and  local  ICP  files. 

(4)  The  proper  information  is  annotated  for  each  item 
which  is  then  returned  to  the  IEB. 

m.  Advice  Decision.  This  major  event  consists  of  three 
subevents . 


(1)  From  the  information  returned  to  the  IEB  by  the 
Cataloging  Branch,  an  advice  is  determined  for  each  item. 

(2)  Advice  transactions  are  generated  for  each  item 
containing  the  determined  advice  and  a  Date  of  Advice  equal  to 
the  Current  Data  plus  five  days. 

(3)  The  advice  transactions  are  mailed  to  the  SICC. 

n.  File  Maintenance.  This  major  event  consists  of  a 
single  subevent  to  update  the  Incoming  SSR  History  File. 

(1)  A  duplicate  advice  transaction  is  filed  with 
the  original  SSR  transactions  in  the  Incoming  SSR  History  File. 
The  advice  is  annotated  on  the  SSR  transaction  list.  When  accept 
or  reject  advice  has  been  forwarded  to  the  SICC  for  all  items  on 
the  list,  it  is  destroyed. 

o.  Requirements  Determination.  This  major  event  con¬ 
sists  of  two  subevents. 

(1)  For  items  on  which  support  was  rejected,  the 
skeleton  PPR  transactions  are  destroyed.  For  items  on  which  sup¬ 
port  was  accepted  after  resolution  of  the  file  discrepancies,  the 
skeleton  PPR  transactions  are  completed  by  the  IEB. 

(2)  The  IEB  forwards  the  completed  transactions  to 
the  CDPD  for  automated  update  of  requirements  files,  to  include 
SSR  requirements  in  recomputation  and  forecasting. 

3.  SICC  SSR  Advice  Processing  Phase.  This  phase  is  accom¬ 
plished  at  '.he  provisioning  activity  which  processes  accept  and 
reject  advice  transactions  and  followup  response  transactions 
from  SPCC.  This  processing  may  result  in  SSR  resubmittal  as 
shown  In  Figure  III-8.  The  resubmittals  are  treated  as  initial 
submittals  by  SPCC. 
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CHAPTER  IV 


AIR  FORCE 


A.  INTRODUCTION 


SSR  generation  and  processing  in  the  Air  Force  is  performed 
by  the  five  Air  Logistics  Centers  (ALCs).  One  of  these  ALCs  , 
Sacramento  Air  Logistics  Center  (SMALC),  was  visited  for  the 
Operational  Implementation  Review  of  the  Air  Force  Automated  SSR 
Subsystem.  SMALC  was  selected  for  review  because  it  is  the  major 
processor  of  SSRs  and  because  it  is  colocated  with  the  design 
activity  of  the  SSR  Subsystem.  SMALC  also  served  as  the  proto¬ 
type  activity  for  testing  and  implementation  of  the  Automated 
SSR  Subsystem. 

This  section  presents  the  operational  system  being  used  at 
SMALC  at  the  time  of  the  review,  followed  by  a  discussion  of 
organizational  elements  involved  in  SSR  generation  and  pro¬ 
cessing.  Presentations  of  Outgoing  Provisioning  SSR  Generation 
and  Processing,  Outgoing  Non p r o v i s io ni n g  SSR  Generation  and 
Processing,  and  Incoming  SSR  Processing  are  given  in  that  order. 
These  presentations  describe  the  processes  found  at  SMALC  and, 
although  all  the  ALCs  are  tied  to  specific  AFLC  Regulations, 
minor  differences  in  processing  procedures  may  occur  among  them. 

B .  AIR  FORCE  AUTOMATED  OPERATIONAL  SYSTEM  DESCRIPTION 

1.  Implementation  Status.  The  Automated  SSR  Subsystem  in 
the  Air  Force  was  designed  as  two  separate  applications.  One 
application  was  designed  to  handle  processing  on  a  daily  basis. 
The  second  application  was  designed  to  perform  monthly  pro¬ 
cessing.  The  Daily  SSR  Application  was  implemented  by  all  ALCs 
concurrently  with  the  implementation  of  the  IMM  Manual  on  1  May 
1978.  The  Monthly  SSR  Application  was  implemented  by  all  ALCs 
by  30  June  1978.  Both  of  these  applications  were  operational  at 
SMALC  during  the  implementation  review.  However,  the  Provision¬ 
ing  Subsystem  was  not  operational  during  the  review.  Provision¬ 
ing  processing  during  the  review  was  totally  manual;  this  manual 
processing  is  reflected  in  the  discussion  below.  The  Provision¬ 
ing  Subsystem  and  the  SSR  Subsystem  were  both  operational  at  all 
ALCs  except  San  Antonio  ALC  (SAALC)  by  the  end  of  1979. 

2.  Operational  System  Description.  The  automated  opera¬ 
tional  system  is  illustrated  in  Figure  IV-1.  A  comparison  of 
this  figure  and  Figure  IV-3  in  Part  1  of  this  Volume  shows  that 
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other  than  the  Provisioning  Subsystem  interfaces,  the  SSR  Sub¬ 
system  inputs,  outputs  and  files  are  identical.  Processing  is 
also  identical  and,  since  this  subsystem  was  described  in  detail 
in  Part  1  of  this  Volume,  it  will  not  be  discussed  here.  The 
SSR  Daily  Application  is  executed  three  times  per  week  at  SMALC. 

C.  AIR  FORCE  SICC/WIMM  ORGANIZATIONAL  STRUCTURE 


Each  Air  Logistics  Center  is  responsible  for  item  selection, 
SM&R  coding  and  IMC  during  provisioning  of  equipments.  This 
responsibility  includes  method  of  management  decisions  indicating 
which  items  will  be  retained  for  management  by  the  Air  Force 
ALCs,  which  consumable  items  require  SSRs  to  be  sent  to  another 
Service  activity  as  the  WIMM  or  to  DLA/GSA  as  the  CIMM,  and  which 
reparable  items  require  NIMSRs  to  be  prepared  and  sent  to  another 
Service  activity  as  the  Lead  ICP.  Method  and  Level  of  Support 
determinations  are  made  for  items  retained  by  the  Air  Force  for 
management.  The  organizational  structure  is  similar  at  all  the 
ALCs;  however,  the  structure  presented  here  is  that  found  at 
SMALC . 

The  SICC/WIMM  organizational  structure  shown  in  Figure  IV-2 
reflects  the  particular  elements  involved  in  SSR  generation  and 
processing.  Because  of  the  organizational  arrangement  in  the 
Air  Force,  it  is  necessary  to  view  the  SICC/WIMM  organizational 
structure  as  illustrated  by  this  figure.  The  primary  thrust  of 
SSR  generation  and  processing  is  contained  within  the  Item  Man¬ 
agement  Division  at  SMALC;  the  AFLC  Cataloging  and  Standardiza¬ 
tion  Office  (CASO)  which  is  physically  located  at  Battle  Creek, 
Michigan,  but  is  under  the  direct  control  of  the  D CS /Log is t i c s 
Operations  at  HQ,  AFLC;  and  the  Comptroller  Division  of  the 
2851nd  Air  Base  Group  which  is  colocated  with  SMALC.  Each  of  the 
particular  elements  within  these  Divisions  and  CASO  will  be  dis¬ 
cussed  in  terms  of  the  events  performed  in  SSR  generation  and 
processing. 

1.  AFLC  Cataloging  and  Standardization  Office  (CASO).  This 
Office  is  the  centralized  activity  in  the  Air  Force  responsible 
for  all  cataloging  functions.  It  serves  as  the  interface  between 
the  Air  Force  ALCs  and  DLSC  for  entry  of  all  management  data  into 
DLSC  files.  This  Office  also  maintains  all  Air  Force  cataloging 
files.  The  primary  SSR  related  functions  performed  by  this  Of¬ 
fice  include  reviewing  substitute  item  offers  from  DLA  IMMs  and 
a c ce p t i ng / r e jec t i n g  the  offered  item,  performing  DLSC  screening 
for  nonprovisioning  SSR  candidates  submitted  by  Air  Force  Bases 
as  Requests  for  Cataloging  Action,  taking  appropriate  action  to 
lodge  Air  Force  peculiar  management  data  on  DLSC  files,  and 
taking  action  to  add  other  service  activities  as  users  of  Air 
Force  managed  items. 
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2.  Item  Management  Division.  This  Division  at  SMALC  is 
where  all  manual  processing  related  to  SSR  generation  and  pro¬ 
cessing  is  performed.  Three  branches  within  this  Division  are 
involved  as  illustrated  in  Figure  IV-2.  These  branches  are  the 
Materiel  Support  Branch  (MSB),  Engineering  and  Reliability 
Branch  (ERB)  and  Stock  Fund  Branch  (SFB). 

a.  The  Materiel  Support  Branch  has  two  sections  per¬ 
forming  SSR  related  functions,  the  Provisioning  Section  and  the 
Supply  Support  Section. 

(1)  The  Provisioning  Section  has  three  units  which 
perform  SSR  functions:  the  Aircraft  Unit,  Space  S y s t e ms / Ge ne r a t o r / 
Lateral  Unit  and  Catalog/SSR  Unit. 

(a)  Aircraft  Unit.  This  unit  consists  of  pro¬ 
visioning  technicians  who  initially  receive  the  PTD  submitted  by 
the  contractor  and  are  responsible  for  reviewing  it  for  complete¬ 
ness.  The  prjvisioning  technicians  perform  DLSC  screening  when 
it  has  not  been  done  by  the  contractor  or  when  contractor  screen¬ 
ing  results  are  obsolete.  The  provisioning  technician  identifies 
SSR  candidate  items  and  forwards  these  items  and  required  tech¬ 
nical  data  to  the  Catalog/SSR  Unit  for  further  processing.  The 
provisioning  technician  monitors  the  provisioning  of  an  end  item 
from  the  time  the  PTD  is  received  from  the  contractor  until  every 
support  item  has  been  accepted  for  support  by  an  Air  Force  ALC 

or  other  I MM. 

(b)  Space  Sy s t ems / Gene r a t o r / La t e r a  1  Unit.  This 
unit  also  consists  of  provisioning  technicians  performing  iden¬ 
tical  actions  to  those  described  for  the  Aircraft  Unit  above. 


(c)  Catalog/SSR  Unit.  This  unit  is  made  up  of 
control  clerks,  supply  clerks  and  supply  technicians.  Control 
clerks  generally  control  all  incoming  and  outgoing  products  (data 
transcripts,  mail,  EAM  cards,  etc.)  for  the  unit.  The  supply 
clerks  and  supply  technicians  perform  many  of  the  same  functions 
interchangeably.  This  unit  is  where  all  SSR  transactions  orig¬ 
inate  and  where  all  incoming  SSR  transactions  are  received  and 
initially  processed.  All  inputs  and  outputs  from  the  automated 
SSR  Subsystem  come  from  and  are  delivered  to  this  unit  for  ini¬ 
tial  review.  This  unit  reviews  all  incoming  and  outgoing  SSR 
transactions  and  attempts  to  correct  any  errors  encountered 
either  through  manual  review  or  automated  validation.  Manual 
files  are  maintained  for  all  SSR  transactions  processed  and  final 
advice  is  forwarded  to  the  SSR  originator. 


(2)  Supply  Support  Section.  The  Special  Programs 
Unit  within  this  section  performs  requirements  determination  for 
outgoing  nonprovisioning  SSR  canuidate  items.  In  this  unit 
requirements  are  reviewed,  if  furnished,  or  a  decision  is  made 
whether  to  compute  SSR  requirements  manually,  or  have  it  done  by 
the  SSR  Subsystem.  Also  this  unit  may  generate  I MC  adopt  trans¬ 
actions  for  use  in  lieu  of  SSR  transactions. 

b.  Engineering  and  Reliability  Branch  (ERB).  This 
branch  consists  of  equipment  specilists  who  generally  assign 
S  Mf>  R  codes,  I  M  C  and  FSC  for  new  items.  Other  technical  data 
elements  are  also  assigned  in  this  branch  for  outgoing  provi¬ 
sioning  and  nonprovisioning  SSR  candidates.  The  equipment  spe¬ 
cialists  generally  perform  DLSC  screening  for  non p r o v i s i on i n g 
SSR  candidates  identified  at  the  ALC. 

c.  Stock  Fund  Branch  (SFB).  This  branch  is  made  up  of 
Item  Managers  (IMs)  responsible  for  managing  consumable  items 
for  which  the  ALC  has  cognizance.  These  IMs  are  responsible 
for  determination  of  Method/Level  of  Support  for  items  managed 
by  the  ALC.  This  branch  is  involved  only  in  incoming  SSR  pro¬ 
cessing  and  may  change  the  Method/Level  of  Support  based  on  SSR 
requirements.  The  IMs  review  incoming  SSR  requirements  and  up¬ 
date  requirements  records  and  initiate  procurement  action  when 
necessary.  The  advice  decision  to  be  returned  to  the  SICC  is 
reached  in  this  branch. 

3.  Comptroller  Division.  The  Data  Automation  Branch  func¬ 
tions  as  the  data  processing  organization  for  both  the  2852nd 
Air  Base  Group  and  the  colocated  SMALC.  This  branch  provides 
keypunch  support  and  is  responsible  for  scheduling  and  executing 
the  SSR  Subsystem  for  the  ALC. 

D .  OUTGOING  PROVISIONING  SSR  GENERATION  AND  PROCESSING 

The  Air  Force  Outgoing  Provisioning  SSR  Operational  System 
used  at  SMALC  is  illustrated  in  Figure  IV-3.  This  operational 
system  extends  from  the  time  the  contractor  is  developing  a  PTD 
package  until  support  is  accepted  by  an  I  MM  or  provided  by  an 
Air  Force  ALC.  This  figure  displays  the  system  in  terms  of 
phases  and  major  events;  the  discussion  of  this  operational 
system  is  keyed  to  subevents  within  each  of  the  major  events 
shown  in  Figure  IV-3.  The  relationship  between  the  phases, 
major  events  and  subevents  as  well  as  the  organizational  ele¬ 
ments  performing  each  subevent  is  shown  in  Figure  IV-4.  The 
operational  system  shown  contains  no  processing  priorities  and 
is  not  used  to  process  Design  Change  Notices  (DCNs). 
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DCNs  are  processed  at  SMALC  based  on  the  type  action  required 
additional  quantities,  reduced  quantities,  replaced  item/ supersed 
ing  item  combination,  or  other  change.  DCNs  in  relation  to  SSR 
items  are  dependent  on  the  status  of  the  original  SSR  transaction 
submitted.  DCNs,  indicating  an  additional  quantity  of  the  items 
is  required,  are  processed  by  generating  an  interrogation  to  the 
SSR  Suspense  File.  When  a  match  is  found,  the  total  quantity  is 
compared  to  the  quantity  originally  submitted.  A  new  SSR  is 
generated  for  the  difference  in  quantities.  If  no  match  is  found 
on  the  SSR  Suspense  File,  an  initial  submission  SSR  is  generated 
for  the  total  quantity  required. 

DCNs  indicating  a  reduction  in  quantity  also  have  interroga¬ 
tions  generated  for  matching  against  the  SSR  Suspense  File. 

When  a  match  is  found,  an  SSR  reflecting  the  reduction  in  quan¬ 
tity  is  generated.  When  no  match  is  found,  the  DCN  is  returned 
to  the  provisioning  technician  without  further  action. 

DCNs  indicating  replaced  item/superseding  item  combinations 
have  interrogations  generated  for  the  replaced  item  against  the 
SSR  Suspense  File.  When  a  match  is  found,  the  appropriate 
replaced  item/superseding  item  SSR  transactions  are  generated. 
When  no  match  is  found,  an  initial  submission  SSR  is  generated 
for  the  superseding  item. 

Other  SSRs  requiring  changes  to  be  submitted  are  accomplished 
by  processing  a  delete  SSR  for  the  current  SSR  transaction  and 
generating  a  new  SSR  for  the  required  changes.  All  SSR  transac¬ 
tions  generated  are  processed  through  the  Daily  SSR  Application 
for  validation  and  posting  to  the  SSR  Suspense  File.  Action 
taken  on  items  is  annotated  on  the  DCN  before  it  is  returned  to 
the  provisioning  technician. 

1 .  Contractor  Processing  Phase.  As  shown  in  Figures  IV-3 
and  IV-4  this  processing  phase  consists  of  two  major  events; 

DLSC  Screen  and  Prepare  PTD. 

a.  DLSC  Screen.  This  major  event  consists  of  three 
subevents  and  is  accomplished  when  contractor  screening  is  a 
contractual  requirement. 

(1)  The  contractor,  in  the  initial  stages  of  pre¬ 
paring  PTD,  identifies  items  he  will  recommend  be  source  coded 
in  the  ' P  '  series. 

(2)  These  'P'  code  recommended  items  are  screened 
against  DLSC  files  to  identify  items  already  having  an  NSN 
assigned. 

(3)  The  results  from  the  DLSC  screen  become  part  of 
the  PTD  and  are  forwarded  to  the  provisioning  ALC. 
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b.  Prepare  PTD.  This  major  event  consists  of  a  single 
subevent . 


(1)  The  contractor  completes  the  PTD  package  and 
forwards  It  to  the  provisioning  ALC  for  processing. 

2.  Provisioning  Processing  Phase.  This  processing  phase 
consists  of  five  major  events:  DLSC  Screen,  Manual  File  Estab¬ 
lishment,  SM&R,  IMC  and  File  Maintenance. 

a.  DLSC  Screen .  This  major  event  consists  of  six  sub¬ 
events  . 

(1)  PTD  received  from  the  contractor  is  generally 
in  hard  copy  form  and  is  received  at  the  ALC  by  a  provisioning 
technician . 

(2)  The  provisioning  technician  reviews  the  PTD 
package  and  is  responsible  for  obtaining  any  additional  data 
required  from  the  contractor.  The  PTD  is  next  reviewed  to  deter¬ 
mine  if  DLSC  screening  was  performed  by  the  contractor.  Addi¬ 
tional  'P'  code  candidates  may  also  be  identified  by  the  provi¬ 
sioning  technician. 

(3)  When  the  contractor  did  not  perform  DLSC  screen¬ 
ing,  additional  'P'  code  candidates  are  identified  or  the  con¬ 
tractor  screening  results  are  obsolete,  new  DLSC  screening  trans¬ 
actions  are  prepared. 

(4)  These  transactions  are  transmitted  to  DLSC  via 
AUTODIN  and  screened  against  DLSC  files  with  responses  returned 
to  the  ALC. 

(5)  Hard  copy  DLSC  results  are  printed  and  returned 
to  the  provisioning  technician. 

(6)  The  provisioning  technician  reviews  the  DLSC 
screening  results  and  makes  appropriate  changes  to  the  PTD. 

b.  Manual  File  Establishment.  This  major  event  con¬ 
sists  of  two  subevents. 

(1;  he  provisioning  technician  establishes  a  manual 
provisionir  ft.  ind  prepares  a  Provisioning  Document  Control 
Card  with  Juspeh.e  of  44  days  for  completion  of  provisioning 
act  ions  . 


(2)  The  PTD  is  then  forwarded  to  the  Equipment 
Specialist  for  determination  of  technical  data. 


352 


I 


c.  SM&R .  This  major  event  consists  of  three  subevents. 

(1)  The  PTD  is  reviewed  by  the  equipment  specialist 
to  determine  the  required  technical  data. 

(2)  The  SM&R  codes  are  assigned  to  each  item  in  the 

PTD. 

(3)  Assigned  codes  and  other  technical  data  are 
annotated  on  the  PTD. 

d.  IMC .  This  major  event  consists  of  three  subevents. 

(1)  The  equipment  specialist  next  assigns  IMC  and 
FSC  for  appropriate  items. 

(2)  These  codes  are  annotated  on  the  PTD. 

(3)  The  PTD  is  returned  to  the  provisioning  tech¬ 
nician. 

e.  File  Maintenance.  This  major  event  consists  of  two 
subevents . 

(1)  The  provisioning  technician  updates  the  manual 
provisioning  file  and  clears  the  suspense  for  completion  of  the 
PTD  package. 

(2)  The  provisioning  technician  then  splits  out  the 
PTD  into  management  categories.  The  Air  Force  has  grouped  all 
items  into  five  management  catagories.  Each  ALC  is  responsible 
for  one  of  these  management  catagories.  All  items  except  SSR 
candidates  are  split  out  into  the  appropriate  management  cate¬ 
gory.  Items  currently  managed  by  SMALC,  or  falling  into  the 
SMALC  management  category,  are  forwarded  to  the  appropriate  IM 
for  further  processing.  Items  currently  managed  by  other  ALCs 

or  falling  in  another  ALC's  management  category  are  mailed  to  the 
appropriate  ALC  for  further  processing.  SSR  transactions  are 
not  used  for  intra-Air  Force  support.  All  SSR  candidates  are 
forwarded  to  the  Catalog/ SSR  Unit. 

3.  SICC  SSR  Processing  Phase.  This  phase  consists  of  five 
major  events,  as  illustrated  by  Figure  IV-3,  and  is  where  the 
Automated  SSR  Subsystem  is  used. 

a.  Manual  File  Establishment.  This  major  event  con¬ 
sists  of  eleven  subevents. 
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(1)  The  control  clerk  in  the  Catalog/SSR  Unit 
receives  SSR  candidate  items  and  associated  technical  data  from 
the  provisioning  technician. 

(2)  The  control  clerk  establishes  an  internal 
suspense  (usually  15  days)  for  processing  candidates  into  the 
Daily  SSR  Application. 

(3)  A  PCC  folder  is  prepared  and  placed  in  a  file 
cabinet  reserved  for  them. 

(4)  The  SSR  unit  supervisor  spot  checks  SSR  can¬ 
didates  for  completeness  and  forwards  them  to  a  supply  technician 
for  generation  of  SSR  transactions.  Incomplete  candidates  are 
returned  to  the  provisioning  technician. 

(5)  The  supply  technician  acts  on  SSR  candidates 
assigned  to  him,  based  on  the  suspense  date.  Candidates  with 
the  closest  suspense  due  date  are  processed  first. 

(6)  The  supply  technician  extracts  the  PCC  folder 
from  the  file  cabinet. 

(7)  Each  SSR  candidate  in  the  PCC  folder  is  checked 
for  completeness  of  required  data.  Incomplete  items  are  returned 
to  the  provisioning  technician. 

(8)  SSR  candidate  items  which  are  complete  are  for¬ 
matted  into  the  required  PDSSR,  LISSR,  Item  Name,  Additional 
Reference  Number  and  Additional  User  Transactions.  The  part 
number  items  are  identified  to  a  drawing  or  other  appropriate 
technical  data  in  the  PCC  folder  at  this  time.  The  ISN,  FSC, 

PCC  and  other  control  data  are  annotated  on  the  technical  data. 

(9)  The  technical  data  and  other  data  are  filed  in 
the  PCC  folder  to  await  computer  processing  of  the  formatted  SSR 
transact! ons  . 

(10)  Formatted  SSR  transactions  are  forwarded  to  the 
Data  Automation  Branch  (DAB)  for  keypunching  and  return. 

(11)  Keypunched  SSR  transactions  are  batched  by  the 
control  clerk  for  input  to  the  Daily  SSR  Application. 

b.  Edit/Validation.  This  major  event  consists  of  three 
8  u  be  ven  t  s  . 

(1)  SSR  transactions  are  input  by  the  DAB  to  the 
Daily  SSR  Application. 


(2)  Input  transactions  are  validated  by  the  Daily 
SSR  Application. 

(3)  Transactions  containing  validation  errors  are 
rejected  and  terminate  processing.  They  are  printed  on  the 
Input  Errors  listing  for  manual  review,  correction  and  reinput. 

c.  DLSC  Screen.  This  major  event  consists  of  four 
subevents . 

(1)  Valid  SSR  transactions  have  DLSC  screening 
inquiries  automatically  generated  for  both  NSN  and  part  number 
items . 

(2)  These  items  remain  on  a  suspense  file  awaiting 
a  reply  from  DLSC  for  seven  days,  or  until  a  reply  is  received, 
whichever  is  shorter.  When  DLSC  replies  are  received  within  the 
seven  days,  the  data  in  the  SSR  is  compared  with  data  returned 
from  DLSC.  Based  on  this  comparison,  the  NSN,  ACC,  Unit  of 
Issue,  or  managing  activity  code  may  be  revised. 

(3)  SSR  transactions  containing  an  NSN  are  matched 
against  the  Positive  NSN  Table  File. 

(4)  The  extended  dollar  value  of  each  SSR  transac¬ 
tion  is  computed.  SSR  transactions  containing  an  NSN  that  match 
the  Positive  NSN  Table  File  and  have  an  extended  dollar  value 
less  than  or  equal  to  $1,000  terminate  processing.  These  trans¬ 
actions  are  printed  on  the  Supply  Support  List  with  a  special 
code  indicating  the  item  will  be  supported  without  an  SSR  trans¬ 
action  being  submitted.  Items  with  an  extended  dollar  value 
over  $1,000  are  printed  on  the  SSR  Items  with  Total  Dollar  Value 
over  $1,000  for  Review  List  and  posted  to  the  SSR  Suspense  File 
under  an  internal  suspense  of  15  days  to  complete  the  review  and 
respond . 

d.  Requirements  Determination.  This  major  event  con¬ 
sists  of  two  subevents. 

(1)  SSR  transactions  which  require  computation  of 
retail  and  replenishment  quantities  have  these  quantities  com¬ 
puted  . 

(2)  These  computed  quantities  are  inserted  in  the 
SSR  transaction. 

e.  File  Maintenance.  This  major  event  consists  of  nine 
subevents . 


(1)  Valid  SSR  transactions  are  posted  to  the  SSR 
Suspense  File.  A  suspense  of  40  days  is  placed  on  NSN  items  and 
a  suspense  of  75  days  is  placed  on  part  number  items  for  return 
of  advice  from  an  IMM. 

(2)  The  Daily  SSR  Application  produces  various  out¬ 
put  products  in  each  cycle.  DLSC  replies  are  printed  as  DLSC 
Screening  Results.  SSR  transactions  which  contain  validation 
errors  are  listed  on  the  Input  Errors  list.  All  SSR  transactions 
input  are  listed  on  the  Source  SSR/Advice  Input  list.  SSR  trans¬ 
actions  meeting  the  extended  dollar  value  criteria  are  listed  on 
the  SSR  Items  with  Total  Dollar  Value  over  $1,000  for  Review  List. 
When  the  suspense  on  these  items  is  not  cleared  the  SSR  transac¬ 
tions  are  listed  on  the  Reply  Past  Due  for  over  $  1 , 000 / Re v i e w 
Items.  SSR  Transactions  not  meeting  the  $1,000  review  criteria 
are  listed  on  the  Supply  Support  Request  List.  SSR  cards  are 
produced  for  transactions  on  the  Supply  Support  Request  List 
which  did  not  match  to  the  Positive  NSN  Table  File. 

(3)  The  output  products  are  forwarded  to  the  supply 
technician  for  review. 

(4)  SSR  transactions  rejected  because  of  validation 
errors  are  corrected  and  prepared  for  reinput  to  the  Daily  SSR 
Application. 


(5)  Technical  data  from  the  PCC  folder  is  married 
to  the  appropriate  SSR  cards  and  cover  letters  are  prepared  for 
transmitting  the  packages  to  the  I  MM s . 

(6)  SSR  transaction  packages  are  mailed  to  the 
appropriate  IMMs. 

(7)  The  Supply  Support  List  is  returned  to  the  pro¬ 
visioning  technician  and  the  control  clerk  clears  the  internal 
suspense  on  submitted  items. 

(8)  The  PCC  folder  is  placed  in  the  control  file 
awaiting  advice  from  IMMs  and  results  of  invalid  SSR  transac¬ 
tions  resubmitted  to  the  Daily  SSR  Application.  When  all  items 
are  complete,  the  PCC  folder  is  filed  in  the  completed  file,  and 
after  two  years,  is  purged  from  the  file. 

(9)  The  Daily  SSR  Application  will  automatically 
generate  followup  transactions  for  AUTODIN  transmittal  to  IMMs 
when  advice  has  not  been  received  <-:ithin  40  days  for  NSN  items 
and  75  days  for  part  number  Items.  When  advice  is  not  received 
after  95  days  for  NSN  items  and  130  days  for  Part  Number  items, 
they  are  listed  on  the  Reply  to  Supply  Support  Request,  Past  Due 
for  functional  notification. 
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A.  IMM  SSR  Processing  Phase.  This  phase  is  performed  at 
other  Service  activities,  DLA  and  GSA.  SSR  transactions  are 
processed  by  these  activities  resulting  in  ac  c  e  p  t  /  o  f  f  e  r  /  r  e  j  ec  t  / 

NAN  notification  advice  transactions  being  returned  to  SMALC. 
Followup  transactions  are  also  processed  by  these  activities, 
resulting  in  Followup  Response  transactions. 

5.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
consists  of  the  five  major  events.  Processing  in  the  first  two 
events  ( Ed i t / Va 1 i d a t i on  and  File  Maintenance)  are  the  same  for 
all  advice  transactions  shown  in  Figure  IV-3  as  input  to  this 
processing  phase;  however,  processing  differs  for  the  other  major 
events  depending  on  the  advice  returned.  These  last  three  major 
events  are  discussed  separately  for  accept  advice  (accept  advice 
transactions,  NSN  notification  transactions,  and  Followup  Response 
transactions  containing  accept  advice),  offer  advice  (offer  advice 
transactions  and  Followup  Response  transactions  containing  offer 
advice),  and  reject  advice  (reject  advice  transactions  and  Follow¬ 
up  Response  transactions  containing  reject  advice). 

a •  Edlt/Validatlon .  This  major  event  consists  of  four 
subevents . 

(1)  Advice  transactions  are  received  by  mail  in  the 
Catalog/SSR  Unit  by  the  control  clerk.  Advice  transactions 
received  via  AUTODIN  are  automatically  routed  to  DAB. 

(2)  The  control  clerk  forwards  transactions 
received  by  mail  to  the  DAB  for  input  to  the  Daily  SSR  Appli¬ 
cation. 

(3)  The  SSR  Application  validates  these  transac¬ 
tions  for  format  and  content.  They  must  also  match  a  LISSR  on 
the  SSR  Suspense  File. 

(4)  Advice  transactions  found  invalid  terminate 
processing  and  are  printed  on  the  Input  Errors  list  for  func¬ 
tional  action. 

b.  File  Maintenance.  This  major  event  consists  of  four 
subevents . 

(1)  Valid  advice  transactions  are  posted  to  the  SSR 
Suspense  File.  When  accept  advice  transactions  are  received, 
those  containing  Air  Force  catalog  ng  data  are  automatically 
generated  for  AUTODIN  transmm  I  uO  CASO.  Reject  advice  trans¬ 
actions  containing  certain  reject  codes  automatically  have  SSR 
resubmittals  generated  and  output  for  mailing  to  the  IMM  as 
described  in  Part  1  of  this  Volume. 


(2)  An  internal  suspense  of  15  days  is  placed  on 
offer  advice  transactions.  An  internal  suspense  of  30  days  is 
placed  on  reject  advice  transactions  other  than  those  from  which 
SSR  resubmittals  are  automatically  generated.  When  action  is 
not  taken  to  generate  transactions  to  clear  the  suspense  within 
the  specified  timeframes,  these  items  are  output  to  the  Reply 

to  SSR  Advice  Past  Due  listing  as  an  internal  followup. 

(3)  Advice  transactions  input  to  the  Daily  SSR 
Application  result  in  several  output  products  other  than  those 
discussed  above.  All  advice  transactions  input  are  listed  on 
the  Source  SSR/Advice  Input  listing.  Accept  advice  transactions 
are  listed  on  the  SSR  Positive  Advice  Notice.  Offer  and  reject 
advice  transactions  are  listed  on  the  SSR  Negative  Advice  Notice. 
SSR  resubmittals  are  listed  on  the  Supply  Support  Request  List 
and  are  punched  on  standard  EAM  cards. 

(4)  Advice  transactions  received  by  mail  are 
returned  to  the  control  clerk  with  the  output  products  and  are 
retained  as  a  history  of  advice  received. 

c.  Accept  Advice.  Two  of  the  remaining  three  major 
events  are  performed  when  accppt  advice  is  received. 

(1)  Advice  Review.  This  major  event  consists  of  a 
single  subevent. 


(a)  When  output  products  are  received  by  the 
control  clerk  in  the  Catalog/SSR  Unit,  the  SSR  Positive  Advice 
Notices  are  separated  from  the  remaining  listings  and  cards. 

(2)  Notification  Actions.  This  major  event  con¬ 
sists  of  a  single  subevent. 

(a)  The  SSR  Positive  Advice  Notices  are  for¬ 
warded  to  the  appropriate  provisioning  technicians  as  notifica¬ 
tion  of  acceptance  of  support  by  the  IMM. 

d.  Offer  Advice.  There  are  three  major  events  remaining 
for  processing  of  offer  advice  transactions:  advice  review,  noti¬ 
fication  actions  and  file  maintenance. 

(1)  Advice  Review .  This  major  event  consists  of 
four  subevents. 


(a)  Offer  advice  must  be  reviewed  by  CASO .  A 
copy  of  the  offer  is  automatically  mailed  to  CASO  as  well  as  to 
the  ALC  by  the  IMM. 
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(b)  CASO  determines  if  the  offer  will  be 
accepted  or  rejected.  The  decision  is  forwarded  to  the  provi¬ 
sioning  ALC  and  arrives  in  the  Catalog/SSR  Unit  at  SMALC. 

(c)  Offer  reply  transactions  are  formatted  and 

keypunched . 

(d)  These  transactions  are  forwarded  to  the 
DAB  for  input  to  the  Daily  SSR  Application. 

(2)  Notification  Actions.  This  major  event  con¬ 
sists  of  a  single  subevent. 

(a)  The  control  clerk  in  the  Catalog/SSR  Unit 
provides  the  offer  advice  no t i f i c a t i on  ,  the  item  offered  and  the 
CASO  acce pt / re jec t  decision  to  the  appropriate  provisioning 
technician. 


(3)  File  Maintenance.  This  major  event  consists  of 
two  subevents. 

(a)  Offer  reply  transactions  input  to  the 
Daily  SSR  Application  clear  the  automated  15-day  suspense  and 
are  posted  to  the  SSR  Suspense  File. 

(b)  The  offer  reply  transactions  are  generally 
transmitted  to  the  I  MM  via  AUTODIN. 

e  Reject  Advice.  There  are  three  major  events  remain¬ 
ing  in  processing  reject  advice  transactions. 

(1)  Advice  Review.  This  major  event  consists  of 
two  subevents. 


(a)  SSR  Negative  Advice  Notices  are  reviewed 
to  determine  rejected  SSR  transactions  which  require  manual 
correction  for  resubmittal  by  the  supply  technician  in  the 
Catalog/SSR  Unit. 


(b)  When  the  supply  technician  is  able,  he 
determines  the  correct  data  and  formats  a  new  SSR  transaction 
and  forwards  it  to  the  DAB  for  input  to  the  Daily  SSR  Applica¬ 
tion. 


(2)  Notification  Actions.  This  major  event  con¬ 
sists  of  a  single  subevent. 

(a)  When  the  supply  technician  cannot  deter¬ 
mine  the  correct  data,  a  notification  is  prepared  and  forwarded 
to  the  provisioning  technician  who  must  determine  appropriate 
action. 
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(3)  File  Maintenance.  This  major  event  consists  of 
four  subevents. 

(a)  The  resubmittals  generated  by  the  supply 
technician  are  input  to  the  Daily  SSR  Application  for  processing 
by  DAB.  These  resubmittals  are  processed  as  initial  submissions 
except  they  must  clear  the  automated  30-day  suspense.  The  SSR 
tiansactions  generated  are  returned  to  the  Catalog/SSR  Unit  for 
mailing  to  the  I  MM. 

(b)  For  items  returned  to  the  provisioning 
technician  for  action,  file  maintenance  delete  transactions  are 
generated.  These  transactions  delete  the  SSR  transactions  for 
these  items  from  the  SSR  Suspense  File  and  indirectly  clear  the 
automated  suspense  for  these  items. 

(c)  The  file  maintenance  transactions  are  for¬ 
warded  to  the  DAB  for  input  to  the  Daily  SSR  Application  to 
accomplish  the  delete  action. 

(d)  Monthly  SSR  transactions  which  are  not 
complete,  and  have  resided  on  the  SSR  Suspense  File  for  a  year 
or  more,  are  purged  from  the  file  and  listed  on  the  Deleted  One 
Year  Open  Items  list.  This  list  is  forwarded  by  the  supply 
technician  to  the  appropriate  provisioning  technician  for  appro¬ 
priate  action.  Various  other  functional  listings  and  updated 
files  are  produced  on  a  monthly  basis  as  described  in  Part  1  of 
this  Volume. 

E.  OUTGOING  NONPROVISIONING  SSR  GENERATION  AND  PROCESSING 


The  Air  Force  Outgoing  Nonprovisioning  SSR  Operational  System 
is  illustrated  in  Figure  IV-5.  The  organizational  relationships 
are  similar  to  those  of  the  Outgoing  Provisioning  SSR  Operational 
System  already  discussed  since  many  of  the  processing  phases  and 
major  events  are  the  same.  The  primary  difference  between  these 
operational  systems  is  the  origination  of  SSR  candidates  and  the 
actual  documents  used  in  manually  generating  SSR  transactions 
for  initial  input  to  the  Daily  SSR  Application. 

The  requirement  for  non p r o vi s ion i n g  SSR  transactions  may 
originate  outside  of  the  ALC  (at  an  Air  Force  Base),  or  within 
the  ALC,  generally  by  an  equipment  specialist.  When  an  Air  Force 
Base  identifies  an  item,  a  Request  for  Catalog  Action  is  pre¬ 
pared  and  forwarded  to  CASO  for  action.  CASO  performs  DLSC 
screening  on  the  item  and,  when  the  item  is  not  already  managed 
by  the  Air  Force,  the  screening  results  and  the  Request  for 
Cataloging  Action  are  mailed  to  the  appropriate  ALC  for  action. 
These  items  are  initially  processed  at  the  ALC  by  the  equipment 
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specialist.  The  equipment  specialist  generally  identifies 
nonprovisioning  SSR  candidates  from  part  number  requisitions. 
Engineering  Change  Proposals,  Technical  Order  Modifications,  and 
adoption  of  new  systems  through  processes  other  than  provision¬ 
ing.  The  discussion  that  follows  begins  with  the  receipt  of 
these  originating  documents  by  the  equipment  specialist. 

1.  Non p r o vi s i on ing  Processing  Phase.  This  processing  phase 
consists  of  the  five  major  events  shown  in  Figures  IV-5  and  IV-6. 
DLSC  screen,  SM&R,  IMC,  Requirements  Determination  and  File 
Maintenance . 

a.  DLSC  Screen.  this  major  event  consists  of  five 
subevents  . 

(1)  Originating  documents  are  received  by  an  equip¬ 
ment  specialist.  These  documents  may  have  come  directly  to  him 
(e.g..  Engineering  Change  Proposals)  or  may  have  been  forwarded 
to  him  after  initial  review  by  CASO. 

(2)  Each  originating  document  received  is  reviewed 
to  determine  required  actions. 

(3)  When  screening  results  do  not  accompany  an 
orginating  document,  the  equipment  specialist  will  prepare  DLSC 
screening  inquiries  for  transmittal. 

(4)  These  inquiries  are  forwarded  to  the  DAB  for 
AUTODIN  transmittal  to  DLSC.  No  automated  suspense  or  record  is 
kept  of  these  transactions;  however,  if  the  equipment  specialist 
has  not  received  a  reply  in  five  days,  he  will  initiate  action 
to  resubmit  the  inquiry. 

(5)  DLSC  screening  results  are  received  via  AUTODIN 
and  forwarded  to  the  equipment  specialist. 

b.  SM& R .  This  major  event  consists  of  three  subevents. 

(1)  The  equipment  specialist  reviews  the  screening 
results,  originating  document  and  available  technical  data. 

(2)  SSR  candidates  are  selected  and  an  Air  Force 
Nonprovisioning  Data  Sheet  is  initiated  for  each  candidate. 

When  completed,  each  Data  Sheet  will  contain  the  information 
required  to  generate  SSR  transactions. 

(3)  SM&R  codes  are  assigned  to  new  items  and  all 
required  technical  data  is  entered  on  the  Nonprovisioning  Data 
Sheet  . 
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c.  IMC.  This  major  event  consists  of  three  subevents. 

(1)  The  equipment  specialist  determines  the  IMC  for 
each  item  from  DLSC  screening  results  for  NSN  items  o'"  by  assign¬ 
ment  for  new  items. 

(2)  The  IMC  is  entered  on  the  non p r o v  i  s i on i n g  Data 

Sheet  . 

(3)  SSR  candidate  items  are  forwarded  to  the  Special 
Programs  Unit  (SPU)  for  review  by  an  IM. 

d.  Requirements  Determination.  This  major  event  con¬ 
sists  of  five  subevents. 

(1)  The  IM  reviews  each  SSR  candidate  item  for¬ 
warded  to  him. 

(2)  Primary  review  is  in  the  requirements  area. 

The  retail  and  replenishment  quantities  assigned  in  the  originat¬ 
ing  document  are  reviewed  for  reasonableness  and  dollar  value. 

(3)  The  IM  then  determines  the  retail  and  replenish¬ 
ment  quantities  to  be  entered  in  the  SSR  candidate,  or  if  the 
computation  of  SSR  requirements  will  be  done  by  the  Daily  SSR 
Application. 

(  4  )  The  IM  generates  an  IMC  adopt  transaction  for 
SSR  candidates  that  already  have  an  NSN  assigned  and  are  managed 
by  a  DLA  activity.  SSR  transactions  are  not  generated  for  these 
candidates  . 

(5)  SSR  candidate  items  are  then  returned  to  the 
equipment  specialist. 

e.  File  Maintenance.  This  major  event  consists  of  two 
subevents . 

(1)  The  equipment  specialist  reviews  the  items  when 
returned  from  the  IM  and  prepares  a  Nonprovisioning  Data  Sheet 
for  forwarding  to  the  Catalog/SSR  Unit.  Items  for  which  IMC 
Adopt  Transactions  were  generated  are  not  forwarded  to  the  Cata¬ 
log/SSR  Unit,  but  are  sent  to  DLSC  instead.  The  equipment  spe¬ 
cialist  maintains  a  file  of  items  completed  and  those  forwarded 
to  the  Catalog/SSR  Unit  for  SSR  transaction  submittal. 

(2)  The  equipment  specialist  forwards  SSR  Candidate 
Item  Nonprovisioning  Data  Sheets  and  required  technical  data  to 
the  Catalog/SSR  Unit  and  IMC  adopt  transactions  to  DLSC. 
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2.  SICC  SSR  Processing  Phase.  This  phase  consists  of  five 
major  events;  processing  within  these  major  events  is  identical 
to  that  discussed  in  Subsection  D.3.  above,  except  that  notifica¬ 
tions  and  original  documents  are  returned  to  the  equipment  spe¬ 
cialist  and  'or  Air  Force  base  originator  rather  than  the  provi¬ 
sioning  technician.  The  PCC  and  ISN  for  nonprovisioning  SSR 
items  is  assigned  during  this  phase  by  a  supply  technician  just 
prior  to  generating  the  SSR  transactions. 

3.  IMM  SSR  Processing  Phase.  Actions  in  this  processing 
phase  are  identical  to  those  discussed  in  Subsection  D.4.  above. 

4.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
consists  of  five  major  events.  Processing  within  major  events 
is  identical  lo  that  discussed  in  Subsection  D.5.  above,  except 
that  notifications  are  returned  to  the  equipment  specialist 
and/or  Air  Force  Base  originators  rather  than  the  provisioning 
technician. 

F .  AIR  FORCE  INCOMING  SSR  PROCESSING 

The  operational  system  used  at  SMALC  for  processing  incoming 
SSR  transactions  is  illustrated  in  Figure  IV-7.  As  shown  by  the 
figure  processing  at  SMALC  centers  around  the  WIMM  SSR  Processing 
Phase  and  the  WIMM  Fo 1 lo wu p / Of f e r  Reply  Processing  Phase.  Pro¬ 
cessing  in  this  operational  system  is  a  combination  of  manual 
and  automated  actions.  The  automated  actions  include  validation, 
suspense /his  tor v  file  and  followup  processing;  other  actions  are 
predominantly  manual.  There  is  no  distinction  made  in  processing 
provisioning  and  nonprovisioning  SSRs  and  there  is  no  set  order 
or  priority  in  processing  incoming  transactions.  Although  the 
Air  Force  will  accept  and  process  NSN  and  part  number  SSR  trans¬ 
actions  on  an  equal  basis,  specific  procedures  exist  only  for 
NSN  SSR  transaction  processing.  Part  number  SSR  transactions 
and  SSR  change  transactions  are  handled  strictly  on  a  case  by 
case  basis.  The  discussion  that  follows  is  keyed  to  processing 
active  NSN  SSR  transactions  which  constitute  most  of  the  SSR 
transactions  received,  and  for  which  specific  procedures  are 
available  and  used. 

1.  SICC  SSR  Processing  Phase.  This  processing  phase  occurs 
at  a  non-Air  Force  activity,  and  results  in  submission  of  SSR 
transactions  to  an  Air  Force  ALC  as  the  WIMM. 

2.  WIMM  SSR  Processing  Phase.  This  processing  phase  con¬ 
sists  of  twelve  major  events  as  illustrated  in  Figures  IV-7  and 
IV-8.  These  events  include  Ed i t / Va 1 i d a t i on  ,  File  Maintenance, 
Advice  Decision,  File  Maintenance,  Method/Level  of  Support, 
Requirements  Determination,  Advice  Decision,  File  Maintenance, 
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AIR  FORCE  INCOMING  SSB  OPERATIONAL  SYSTEM 


Figure  IV- 
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Figure  IV-8 
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Catalog  Actions  (1)  Generate  Catalog  Actions 
for  Offer  Accepts  to 


Edit/Validation,  File  Maintenance,  Catalog  Actions,  and  File 
Maintenance.  Catalog  Data  Screening  is  generally  not  done  b 
the  Air  Force  for  incoming  SSR  transactions. 


a.  Edit/Validation.  This  major  event  consists  of  three 
subevents;  including  both  a  manual  and  an  automated  validation 
of  incoming  SSR  transactions. 
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Incoming  SSR  transactions  are  received  in  the 
Branch  by  a  supply  clerk. 

The  supply  clerk  manually  validates  each  PCC 
d  for  valid  package  content,  replenishment  quan- 
ntity,  PCC,  DOR,  End  Item  Quantity,  and  unit 
ors  are  found,  they  are  manually  corrected  by 
after  obtaining  the  proper  data  from  the  SICC 
The  SSR  transactions  are  then  forwarded  to  the 
the  Daily  SSR  Application. 
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File  Maintenance.  This  major  event  consists  of  four 


subevents  that  add  valid  transactions  to  the  SSR  Suspense  File 
and  set  up  an  automated  suspense  of  25  days  for  return  of  advice 
An  internal  followup  is  generated  if  25  days  elapse  without 
cycling  a  valid  advice  transaction  through  the  application. 


(1)  After  the  automated  validation,  valid  incoming 
SSR  transactions  are  screened  against  a  local  cataloging  file  to 
obtain  the  Item  Manager  Designator.  This  identifies  an  indivi¬ 
dual  within  the  Stock  Fund  Branch  (SFB)  who  has  management 
responsibility  for  the  item. 
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Integrated  Materiel  Manager,  SSR/Advice  Delinquent  Notice  for 
Air  Force  Weapons  Integrated  Materiel  Manager  and  Reject  Advice 
Transactions  . 

c.  Advice  Decision.  This  major  event  consists  of  a 
single  subevent. 

(1)  The  supply  clerk  mails  the  reject  advice  trans¬ 
actions  from  the  mechanized  validation  to  the  SICC. 

d.  File  Maintenance.  This  major  event  consists  of  two 
subevents  to  establish  a  manual  control  file. 

(1)  When  output  listings  are  received,  a  PCC  folder 
'is  established  for  each  incoming  PCC  package.  A  copy  of  the 
WIMM  SSR  Advice  List,  Input  Errors  and  Source  SSR/Advice  Input 

is  placed  in  the  folder. 

(2)  The  supply  clerk  establishes  a  suspense  for 
return  of  advice  for  items  on  the  SSR/Advice  for  Weapons  Inte¬ 
grated  Materiel  Manager  and  forwards  this  list  and  the  SSR/Advice 
Delinquent  Notice  for  Air  Force  Weapons  Integrated  Materiel  Man¬ 
ager  to  the  Stock  Fund  Branch  (SFB).  This  manual  suspense  is 
relatively  informal,  and  followups  initiated  as  a  result  of  this 
suspense  are  infrequent. 

e.  Method/Level  of  Support.  This  major  event  consists 
of  three  subevents. 

(1)  When  the  item  manager  in  the  SFB  receives  the 
listings  forwarded  to  him,  he  pulls  local  records  kept  on  each 
item  managed  by  the  ALC. 

(2)  When  the  local  records  for  an  item  indicate  the 
item  is  centrally  procured,  nonstocked  or  local  purchase,  the 
Item  is  reviewed  In  terms  of  current  demand  and  SSR  projected 
requirements . 

(3)  When  warranted,  the  item  manager  may  decide  to 
assign  a  new  AAC  and  stock  the  item.  If  so,  he  may  take  action 
to  initiate  the  appropriate  transactions  for  transmittal  to  CASO 
who  will  update  DLSC  and  Air  Force  files.  However,  our  field 
research  indicated  that  this  is  done  infrequently. 

f.  Requirements  Determination.  This  major  event  con¬ 
sists  of  two  subevents. 

(1)  The  Item  manager  in  the  SFB  reviews  local  records 
and  SSR  requirements  to  determine  if  procurement  is  necessary. 
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(2)  The  item  manager  may  initiate  procurement 
actions  for  SSR  quantities  greater  than  available  assets  and 
budgets  for  future  SSR  requirements;  however,  our  field  research 
indicated  that  it  is  done  infrequently. 

g.  Advice  Decision.  This  major  event  consists  of  two 
subevents  to  determine  the  advice  to  be  returned  to  the  SICC. 

(1)  The  item  manager  in  the  SFB,  based  on  his 
review,  determines  the  advice  to  be  returned  to  the  SICC.  This 
advice  is  most  often  accept;  however,  offer  and  reject  advices 
may  also  be  returned. 

(2)  The  advice  is  annotated  on  the  SSR/Advice  for 
Weapons  Integrated  Materiel  Manager  Listing.  When  offer  or 
reject  advice  is  determined,  the  offered  item  or,  reason  for 
reject,  is  annotated  on  the  listing.  When  advice  for  all  items 
on  the  listing  is  determined,  it  is  returned  to  the  supply  clerk 
in  the  Catalog/SSR  Unit. 

h.  File  Maintenance.  This  major  event  consists  of  four 
subevents  to  clear  the  manual  suspense  on  the  SFB  and  format 
advice  transactions. 

(1)  Advice  transactions  are  formatted  by  the  supply 
clerk  from  the  information  on  the  listings  returned  from  the  SFB 
and  the  informal  suspense  on  these  items  is  cleared. 

(2)  The  formatted  advice  transactions  are  given  to 
a  control  clerk  within  the  Catalog/SSR  Unit  for  keypunching. 

(3)  The  keypunched  advice  transactions  are  for- 
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(1)  Valid  advice  transactions  are  posted  to  the  SSR 
Suspense  File  and  the  25-day  suspense  for  the  item  is  cleared. 

If  the  advice  is  an  offer,  a  60-day  suspense  is  established  for 
a  reply  by  the  SICC.  If  a  reply  is  not  received  in  the  60-day 
period,  a  reject  advice  transaction  is  automatically  generated, 
for  return  to  the  SICC.  When  the  reject  advice  is  generated, 
the  60-day  suspense  is  cleared  and  the  item  is  considered  com¬ 
plete.  Accept  and  reject  advice  also  complete  action  for  an 
item  on  the  SSR  Suspense  File. 

(2)  After  posting  to  the  SSR  Suspense  File,  advice 
transactions  are  output  as  cards  and  listed  on  the  WIMM  SSR 
Advice  List.  These  outputs  are  forwarded  to  the  Catalog/SSR 
Unit. 

k.  Catalog  Actions.  This  major  event  consists  of  two 
sube  vents • 

(1)  When  an  accept  advice  is  returned  to  the  SICC, 
the  Daily  SSR  Application  automatically  generates  cataloging 
transactions  for  AUTODIN  transmittal  to  CASO . 

(2)  When  CASO  receives  these  transactions,  the  item 
is  screened  against  DLSC  files  and  Add  User  transactions  are 
generated  when  the  SICC  is  not  registered  as  a  user  of  the  item. 
The  Add  User  transactions  update  DLSC  files  and,  in  turn,  update 
Air  Force  cataloging  files. 

l.  File  Maintenance.  This  major  event  consists  of 
three  subevents. 

(1)  Outputs  from  the  Daily  SSR  Application  are 
reviewed  in  the  Catalog/SSR  Unit.  Input  advice  transactions 
found  to  be  Invalid  are  corrected  for  reinput  to  the  Daily  SSR 
Application . 

(2)  Output  advice  transactions  are  mailed  to  the 
SICC,  along  with  the  listings  annotated  with  reject  advice  infor 
mat  ion . 

(3)  A  copy  of  the  WIMM  SSR  Advice  List  containing 
the  latest  advice  for  each  item  in  the  PCC  package  is  kept  in 
the  PCC  folder.  When  all  items  in  the  PCC  package  are  completed 
the  PCC  folder  is  filed  as  a  manual  history  record. 

3.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
occurs  at  SICC  activities  to  process  advice  transactions  gener¬ 
ated  by  SMALC.  When  an  offer  advice  transaction  is  received  by 
the  SICC,  it  is  required  by  the  IMM  Manual  that  the  SICC  review 
the  offer  and  provide  an  Offer  Reply  transaction  to  the  IMM 
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indicating  acceptance  or  rejection  of  the  offered  item.  Also,  if 
the  SICC  does  not  receive  an  advice  transaction  within  35  days 
of  SSR  transaction  submittal,  the  SICC  may  generate  a  followup 
transaction  and  either  mail  or  transmit  it  via  AUTODIN  to  SMALC. 

4.  WIMM  Followup/Of f er  Reply  Processing  Phase.  This  pro¬ 
cessing  phase  completes  the  processing  cycle  for  incoming  SSR 
transactions  at  SMALC.  SSR  resubmittals  are  processed  identically 
to  initial  submissions,  and  are  not  addressed  separately.  This 
phase  consists  of  three  major  events. 

a.  Edit/Validation.  This  major  event  consists  of  four 
subevents.  * 

(1)  Followup  and  offer  advice  transactions  are 
received  at  SMALC  either  by  mail  or  by  AUTODIN  transmission. 

Those  received  by  mail  come  to  the  Catalog/SSR  Unit. 

(2)  The  supply  clerk  forwards  transactions  received 
by  mail  to  the  DAB  for  input  to  the  Daily  SSR  Application.  Trans¬ 
actions  received  via  AUTODIN  are  automatically  forwarded  to  the 
DAB  for  input  to  this  application. 

(3)  Followup  transactions  and  offer  reply  transac¬ 
tions  are  input  to  the  Daily  SSR  Application  where  they  are 
validated  for  format  and  content.  Offer  Reply  transactions  must 
also  match  a  LISSR  transaction  on  the  SSR  Suspense  File  as  part 
of  the  validation. 

(4)  Invalid  transactions  terminate  processing  and 
are  output  for  manual  action.  The  supply  clerk  attempts  to 
correct  these  transactions  and  reinputs  them.  When  he  cannot 
correct  them,  he  contacts  the  appropriate  SICC,  or  if  he  cannot 
identify  the  SICC,  they  are  destroyed. 

b.  File  Maintenance.  This  major  event  consists  of  four 
subevents . 

(1)  Followup  transactions  are  matched  to  the  SSR 
Suspense  File  for  a  matching  LISSR  transaction. 

(2)  Based  on  the  results  of  the  match,  a  Followup 
Response  transaction  is  automatically  generated  and  output  for 
mailing  to  the  SICC.  The  specific  criteria  for  advice  is  dis¬ 
cussed  in  Part  1  of  this  Volume. 

(3)  Valid  Offer  Reply  transactions  are  posted  to 
the  SSR  Suspense  File  and  clear  the  60-day  suspense. 
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(4)  Offer  Reply  transactions  are  output  to  the  SSR/ 
Advice  for  Weapons  Integrated  Materiel  Manager  List.  This  list 
Is  forwarded  by  the  supply  clerk  In  the  Catalog/SSR  Unit  to  the 
IM  in  the  SFB  for  action  as  appropriate.  Accepted  NSN  offers 
require  no  action,  while  rejected  offers  require  a  new  advice 
decision.  These  rejected  offers  have  an  automated  25-day  suspense 
placed  upon  them.  Advice  must  be  determined  and  input  to  the 
Dally  SSR  Application  to  clear  this  suspense  and  complete  the 
item. 


c.  Catalog  Actions.  This  major  event  completes  incoming 
SSR  transaction  processing  and  consists  of  a  single  subevent. 

(1)  Offer  Accept  transactions  which  indicate  accep¬ 
tance  of  an  offered  NSN  item,  automatically  have  cataloging  trans¬ 
actions  generated  and  transmitted  via  AUTODIN  to  CASO .  These 
transactions  may  be  used  to  generate  Add  User  transactions  to 
DLSC  when  the  SICC  is  not  registered  as  a  user  of  the  accepted 
item. 


379 


V 


I 


CHAPTER  V 
MARINE  CORPS 

A.  INTRODUCTION 


The  Marine  Corps  Logistic  Support  Base  Atlantic  (MCLSBA)  is 
the  sole  Marine  Corps  activity  involved  in  SSR  generation  and 
processing.  MCLSBA  was  visited  as  part  of  the  operational 
implementation  phase  of  research.  This  visit  took  place  prior 
to  the  implementation  of  the  IMM  Manual. 

This  section  first  presents  the  automated  operational  system 
in  use  at  MCLSBA  during  the  visit.  Next  the  organizational  ele¬ 
ments  involved  in  generating  and  processing  SSRs  are  presented. 
This  is  followed  by  discussion  of  outgoing  SSR  generation  and 
processing,  and  incoming  SSR  processing. 

B .  MARINE  CORPS  AUTOMATED  OPERATIONAL  SYSTEM  DESCRIPTION 

1.  Implementation  Status.  The  automated  processing  of  SSRs 
was  in  the  conceptual  phase  of  system  development  at  the  time  of 
the  field  research  visit  to  MCLSBA.  There  was  no  formal  target 
date  set  at  that  time  for  actual  development  or  implementation 
of  the  conceptual  approach  described  in  Part  1  of  this  Volume. 

2.  Operational  System  Description.  The  automated  processing 
interfacing  with  SSR  generation  is  shown  in  Figure  V-l.  A  com¬ 
parison  of  this  figure  to  Figure  V-2  in  Part  1  of  this  Volume 
illustrates  the  differences  between  the  operational  system  and 
the  system  under  development.  The  primary  differences  are  that 
there  is  no  direct  feed  from  the  Provisioning  Subsystem  to  the 
Technical  Data  Management  Subsystem  and  all  SSR  transactions  are 
generated  and  processed  on  a  manual  basis  in  the  operational  sys¬ 
tem,  while  there  is  a  direct  feed  between  these  subsystems  and 
automated  processing  in  the  system  under  development. 

C.  SICC/WIMM  ORGANIZATIONAL  STRUCTURE 


MCLSBA  is  responsible  for  item  selection,  SM&R  coding  and 
IMC  for  provisioning  of  end  items  within  the  Marine  Corps.  The 
method  of  management  function  also  is  the  responsibilty  of  method 
MCLSBA  who  determines  the  items  to  be  retained  for  management, 
the  consumable  items  requiring  SSRs  to  be  generated  and  trans¬ 
mitted  to  IMMs  for  support,  and  reparable  items  requiring  NIMSRs 
to  be  prepared  and  sent  to  Lead  Services  for  support.  MCLSBA 
also  has  the  responsiblity  of  determining  the  method  of  manage¬ 
ment  by  the  Marine  Corps  and  for  items  submitted  to  MCLSBA  as 
the  WIMM  from  other  SICCs- 
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Figure  V-l 


Figure  V-2  shows  the  S I CC / W I MM  organizational  structure  at 
MCL&BA  performing  the  generation  and  process! of  SSRs.  This 
figure  illustrates  that  four  division  k  i/el  organizational  ele¬ 
ments  are  involved  in  SSR  "n-iL.dtion  and  processing:  the  Provi¬ 
sioning  Division,  the  Technical  Operations  Division,  the  Supply 
Operations  Division,  and  the  Marine  Corps  Automated  Se  vices 
Center. 

1.  Provisioning  Division  (PD).  There  are  three  Weapons 
Systems/Equipment  (WS/Equip)  Provisioning  Branches  within  this 
Division.  These  branches  consist  of  provisioning  technicians 
who  initially  receive  and  review  PTD  received  from  the  contrac¬ 
tor.  During  the  provisioning  conference,  the  provisioning  tech¬ 
nicians  assign  SM&R  codes  to  all  items  on  the  provisioning  list. 
Each  branch  maintains  provisioning  files  for  items  currently  in 
the  provisioning  cycle  and  items  for  which  provisioning  has  been 
completed.  The  provisioning  technican  may  also  be  involved  in 
making  ac ce p t / r e j ec t  decisions  for  substitute  items  offered  by 
IMMs. 

2.  Technical  Operations  Division  (TOD).  There  are  five 
branch  level  organizational  elements  within  this  Division  in¬ 
volved  in  SSR  generation  and  processing  as  shown  in  Figure  V-2. 
These  elements  include  the  Operations  Office,  three  WS/Equip 
Support  Data  Branches  and  the  WS/Equip  Support  Technical  Data 
Branch. 


a.  Operations  Office.  This  office  is  responsible  for 
handling  incoming  and  outgoing  correspondence  for  the  division. 
It  also  maintains  correspondence  files  and  an  Item  History  Card 
File  for  provisioning  support  items  which  have  completed  pro¬ 
cessing  . 


b .  WS/Equip  Support  Branches 


Each  of  these  branches  contains  both  catalogers  and 
equipment  specialists.  Cataloging  personnel  perform  most  SSR 
functions,  with  equipment  specialists  providing  technical  assist¬ 
ance  when  necessary,  and  providing  help  in  reaching  accept /re jec t 
decisions  for  substitute  items  offered  by  IMMs. 

Catalogers  within  these  branches  are  responsible  for 
reviewing  PTD  received  from  contractors  for  adequacy, and  perform¬ 
ing  DLSC  screening  for  items  in  the  PTD  when  the  contractor  lid 
not  screen  the  items  or  contractor  screening  is  too  old  to  be 
useful.  Catalogers  assign  IMCs  to  all  'P  '  source  coded  items 
during  the  provisioning  conference  and  prepare  and  submit  SSR 
transactions  to  IMMs.  They  also  maintain  manual  provisioning 
files  and  are  responsible  for  adding  new  items  to  major  Marine 
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Corps  Unified  Materiel  Management  System  (MUMMS)  files.  Cata- 
logers  receive  advice  transactions  from  IMMs  and  prepare  resub¬ 
mittals  for  validation  rejects,  obtain  accept/reject  decisions 
for  substitute  item  offers  and  prepare  offer  reply  transactions 
for  these  items,  and  inform  the  provisioner  when  support  is 
available  for  all  items  on  the  NSN  Required  List.  Obtaining 
NSNs  for  retained  items  is  also  the  responsibility  of  the  cata- 
logers.  On  incoming  SSR  transactions,  catalogers  become  involved 
when  file  discrepancies  exist,  or  research  is  required  because 
items  are  not  on  the  MIF.  Catalogers  also  prepare  required  cata¬ 
loging  transactions  for  incoming  SSRs. 

c.  WS/Equlp  Support  Technical  Data  Branch.  The  Techni¬ 
cal  Data  Respository  is  located  within  this  branch.  All  con¬ 
tractor  furnished  drawings  and  other  technical  data  storage  are 
the  responsibility  of  this  Branch. 

3.  Supply  Operations  Division.  There  are  six  branch  level 
organizational  elements  involved  with  SSR  processing.  These  are 
the  Operations  Office,  and  five  WS/Equip  Branches. 

a.  Operations  Office.  This  Office  receives  all  incoming 
SSR  transactions  and  followups.  These  transactions  are  screened 
against  the  Master  Inventory  File  (MIF).  When  a  match  is  not 
found  the  item  is  forwarded  to  the  Technical  Operations  Division 
for  further  research.  When  a  match  is  found,  the  MIF  is  checked 
for  user  information.  When  the  SICC  is  not  registered  as  a  user, 
the  Operations  Office  notifies  the  Technical  Operations  Division. 
The  Operations  Office  prepares  and  forwards  all  advice  transac¬ 
tions  and  maintains  a  history  file  of  completed  incoming  SSRs. 
This  office  also  processes  and  responds  to  followups  from  SICCs. 

b.  WS/Equip  Branches.  There  are  five  of  these  branches 
within  the  Supply  Operations  Division.  Each  branch  consists  of 
item  managers  responsible  for  requirements  determination  and 
determining  advice  to  be  returned  to  SICCs  for  incoming  SSRs. 

The  item  manager  also  updates  the  MIF  with  user  information  and 
the  Project  Requirements  File  (PRF)  with  SSR  retail  requirements. 

4 .  Marine  Corps  Automated  Services  Center  (MCASC) .  The 
MCASC  provides  computer  support  to  the  functional  divisions 
described  above  and  is  responsible  for  receiving  automated  MUMMS 
inputs,  scheduling  and  executing  MUMMS  Subsystems,  and  distribut¬ 
ing  outputs  to  the  proper  functional  user. 

D.  MARINE  CORPS  OUTGOING  SSR  GENERATION  AND  PROCESSING 


The  Marine  Corps  Outgoing  Provisioning  SSR  Operational  System 
is  shown  in  Figure  V-3.  This  system  begins  with  the  preparation 
of  PTD  by  the  contractor  and  ends  with  notification  to  the  pro¬ 
visioner  that  all  repair  parts  will  be  supported.  Figure  V-3 
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Figure  V-3 


illustrates  the  composition  of  this  operational  system  in  terms 
of  processing  phases  and  major  events  within  these  phases.  The 
Marine  Corps  Outgoing  Provisioning  SSR  Work  Flow  Chart  (Figure 
V-4)  further  breaks  down  these  phases  and  major  events  into  sub¬ 
events  and  the  organizational  elements  performing  each  subevent. 
SSR  change  transactions  resulting  from  Design  Change  Notices 
were  not  researched  during  the  operational  review,  and  genera¬ 
tion  and  processing  of  these  transactions  are  not  addressed  in 
documentation  furnished  to  the  Study  Team.  There  is  an  estab¬ 
lished  processing  priority  for  items  requiring  support. 

Processing  priority  is  based  on  two  criteria;  the  priority 
placed  on  the  end  item,  and  the  manager  of  the  item.  Each  end 
item  in  the  provisioning  process  is  assigned  a  priority  for  pro¬ 
cessing.  This  results  in  all  items  within  the  end  item  having 
the  highest  priority  being  processed  first.  Within  each  end 
item  there  is  also  a  priority  for  processing  support  items.  All 
long  leadtime  items  are  processed  first,  followed  by  all  new 
items  requiring  an  NSN  which  are  retained  for  management  by  the 
Marine  Corps.  Part  number  WIMM  SSR  transactions  are  processed 
third  followed  by  part  number  CIMM  SSR  transactions.  Next  PSCN 
WIMM  SSR  transactions,  followed  by  PSCN  CIMM  SSR  transactions, 
are  processed.  Finally,  NSN  SSR  transactions  are  processed  in 
the  same  WIMM,  then  CIMM,  sequence.  This  processing  priority  is 
most  significant  in  the  Technical  Operations  Division  where  NSN 
assignment  requests  and  SSR  transactions  are  generated  and  pro¬ 
cessed  . 

The  review  of  Marine  Corps  SSR  generation  and  processing 
took  place  prior  to  the  implementation  of  the  new  IMM  Manual. 

As  a  result,  MCLSBA  was  operating  under  the  old  procedures,  re¬ 
quiring  the  use  of  a  DD  Form  1590  for  nonprovisioning  SSRs. 

During  the  Operational  Implementation  Review,  it  was  found  that 
nonprovisioning  SSRs  are  generally  Initiated  within  the  Supply 
Operations  and  Technical  Operations  Divisions.  The  initiator 
furnishes  all  data  required  to  prepare  the  form  for  submittal. 
MCLSBA  uses  IMC  adopt  transactions  in  lieu  of  the  DD  Form  1590 
whenever  possible.  There  were  no  nonprovisioning  SSR  procedures 
developed  at  the  time  of  the  review  for  post  IMM  Manual  imple¬ 
mentation;  however,  it  was  expected  that  IMC  adopt  transactions 
would  continue  to  be  used  whenever  possible  and  nonprovisioning 
SSR  transactions  in  the  new  formats  would  be  generated  and  pro¬ 
cessed  similarly  to  provisioning  SSR  transactions  when  an  IMC 
adopt  transaction  could  not  be  used. 

1.  Contractor  Processing  Phase.  This  processing  phase  con¬ 
sists  of  two  major  events  as  shown  in  Figures  V-3  and  V-4.  These 
major  events  include  preparation  of  PTD  and  DLSC  screening. 

a.  Prepare  PTD.  This  major  event  consist!  of  two  sub- 

events  . 
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Figure  V-4 


(1)  PTD  is  prepared  by  the  contra'  tor  for  submission 

to  MCLSBA. 

(2)  The  PTD  is  submitted  to  MCLSBA  for  review  and 

approval • 

b.  DLSC  Screen .  This  major  event  consists  of  two  sub¬ 
event  s  . 

(1)  Generally,  the  Marine  Corps  includes  DLSC  screen¬ 
ing  as  a  contractual  requirement.  This  places  the  task  of  pre¬ 
paring  DLSC  screening  transactions  on  the  contractor. 

(2)  Due  to  the  volume  of  items  being  screened,  these 
transactions  are  generally  mailed  to  DLSC  for  processing.  Results 
from  this  screening  are  forwarded  directly  to  MCLSBA  for  proces¬ 
sing. 

2.  Provisioning  Processing  Phase.  This  phase  consists  of 
seven  major  events:  DLSC  Screen,  File  Establishment,  SM&R,  IMC , 

File  Maintenance,  Requirements  Determination  and  File  Maintenance. 

a.  DLSC  Screen.  This  major  event  consists  of  seven 
subevents  as  shown  in  Figure  V-4. 

(1)  PTD  is  received  by  the  provisioner  at  MCLSBA 
who  forwards  one  copy  of  the  PTD  to  the  cataloger  for  review. 

Both  the  provisioner  and  cataloger  review  the  PTD  submitted  for 
completeness  and  accuracy.  When  problems  are  identified  with 
the  submitted  PTD,  it  is  returned  to  the  contractor  for  correc¬ 
tion  and  re s u bmi s s i o n  . 

(2)  When  contractor  screening  has  been  done,  the 
screening  results  are  received  by  the  cataloger. 

(3)  When  DLSC  screening  is  not  a  contractual  require¬ 
ment,  or  the  results  from  contractor  screening  are  too  old  to  be 
useful,  the  cataloger  prepares  DLSC  screening  transactions. 

(4)  These  screening  transactions  are  forwarded  to 
MCASC  for  automated  processing. 

(5)  MCASC  inputs  these  transactions  to  the  Technical 
Data  Management  Subsystem  for  processing  and  recording  on  the 
Suspense  File. 

(6)  Screening  transactions  are  forwarded  to  DLSC 
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(7)  The  DLSC  replies  are  automatically  fed  to  the 
Technical  Data  Management  Subsystem  to  clear  the  suspense  file 
to  print  the  DLSC  screening  results  for  forwarding  to  the  cata- 
loger  for  review. 

b.  File  Establishment.  This  major  event  consists  of 
two  sube  vents . 

(1)  When  screening  results  have  been  received  for 
all  items  and  the  remainder  of  the  PTD  is  acceptable,  manual 
provisioning  files  are  established  for  the  item  jointly  by  the 
provisioner  and  the  cataloger  with  the  file  retained  by  the 
cataloger. 


(2)  A  Provisioning  Conference  is  scheduled  and  con¬ 
vened  at  the  contractor  facility.  Events  2.e.  and  2.d.  generally 
occur  at  the  conference. 

c.  SM& R .  This  major  event  consists  of  two  subevents. 

(1)  During  the  provisioning  conference,  the  provi¬ 
sioner  reviews  each  item  in  the  PTD. 

(2)  SM&R  codes  are  assigned  for  each  item. 

d.  IMC .  This  major  event  consists  of  two  subevents. 

(1)  Each  item  source  coded  in  the  'P  '  series  is 
reviewed  by  the  cataloger  at  the  provisioning  conference. 

(2)  The  cataloger  assigns  an  IMC  code  to  each  of 

these  items. 

e.  File  Maintenance.  This  major  event  consists  of  four 
subevents. 

(1)  When  the  provisioner  returns  from  the  provi¬ 
sioning  conference,  he  prepares  transactions  to  load  automated 
provisioning  files.  The  cataloger  prepares  a  manual  history 
card  file  for  all  items  source  coded  in  the  '  P_'  series  at  this 
time. 


(2)  The  provisioner  prepared  transactions  are  for¬ 
warded  to  MCASC  for  input  to  the  Provisioning  Subsystem. 

(3)  MCASC  inputs  the  transactions  into  the  Pro¬ 
visioning  Subsystem. 

(4)  The  input  transactions  are  sorted,  validated 
and  used  to  build  records  on  automated  provisioning  files. 
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f.  Requirements  Determination.  This  major  event  con¬ 
sists  of  three  subevents. 

(1)  The  Provisioning  Subsystem  computes  require¬ 
ments  for  items  established  on  provisioning  files. 

(2)  The  requirements  are  translated  into  retail  and 
replenishment  quantities  for  SSR  candidate  items.  Items  retained 
for  management  by  the  Marine  Corps  requiring  NSN  assignment  and 
SSR  candidate  items  are  printed  on  the  NSN  Required  List. 

(3)  This  list  is  forwarded  to  the  cataloger  via  the 
provisioner  processing. 

g.  File  Maintenance.  This  major  event  consists  of  two 
subevents . 

(1)  The  cataloger  processes  Marine  Corps  retained 
items  by  generating  NSN  assignment  requests  for  these  items. 

(2)  When  the  NSN  assignment  is  received  from  DLSC, 
the  NSN  is  annotated  on  the  Item  History  Card  and  filed  in  a 
completed  file. 

3.  SICC  SSR  Processing  Phase.  This  processing  phase  con¬ 
sists  of  a  single  event. 

a.  File  Maintenance.  This  major  event  consists  of 
thirteen  subevents. 

(1)  Part  Number  SSR  candidate  items  from  the  NSN 
Required  List  are  identified  for  processing. 

(2)  The  Item  History  Card  is  updated  for  each  item. 

(3)  SSR  transactions  are  prepared  using  PTD  anno¬ 
tated  with  the  results  of  the  provisioning  conference,  NSN 
Required  List,  and  DLSC  screening  results. 

(A)  Technical  Data  Is  married  to  the  SSR  transac¬ 
tions  when  available. 

(5)  The  cataloger  prepares  cover  letters  and  mails 
the  SSR  transactions  and  technical  data  to  the  appropriate  IMMs 
for  processing. 

(6)  PSC N / Ina c t i ve  NSN  SSR  candidate  items  from  the 
NSN  Required  List  are  identified  for  processing. 

(7)  The  Item  History  Card  is  updated  for  each  item. 
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(8)  SSR  transactions  are  prepared  for  these  items 
using  the  PTD  annotated  with  results  from  the  provisioning  con¬ 
ference,  DLSC  screening  results,  and  the  NSN  Required  List. 

(9)  Cover  letters  are  prepared  and  the  SSR  transac¬ 
tions  are  mailed  to  the  appropriate  IMMs. 

(10)  The  Item  History  Card  is  updated  for  each  NSN 
SSR  candidate  item  remaining  on  the  NSN  Required  List. 

(11)  SSR  transactions  are  prepared  for  each  NSN  SSR 
candidate  item  except  those  with  both  retail  and  replenishment 
quantities  equal  to  zero.  SSR  transactions  are  not  generated 
for  NSN  SSR  candidate  items  containing  zero  quantities. 

(12)  The  cataloger  prepares  cover  letters  and  mails 
the  SSR  transactions  to  the  appropriate  IMMs. 

(13)  Items  for  which  SSR  transactions  are  generated 
are  placed  in  a  suspense  file  awaiting  advice  from  the  IMMs. 
Followups  to  SSR  transactions  at  MCLSBA  are  generated  manually 
and,  at  the  time  of  the  operational  review,  took  the  form  of  a 
message  requesting  status.  There  was  no  specific  criteria  or 
time  standard  at  MCLSBA  for  submission  of  followups;  however, 
MCLSBA  intends  to  use  the  time  standards  and  formats  in  the  I  MM 
Manual  upon  implementation. 

4.  IMM  SSR  Processing  Phase.  This  processing  is  performed 
at  IMM  activities  and  results  in  advice  being  furnished  the  SICC. 

5.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
consists  of  four  major  events:  File  Maintenance,  Advice  Review, 
File  Maintenance,  and  Notification  Actions.  The  types  of  advice 
that  may  be  received  from  the  IMM  are  also  shown  in  Figure  V-3. 
Since  processing  between  these  types  differ  significantly,  accept 
advice  and  NSN  notifications  are  discussed  first  followed  by  re¬ 
ject  advice.  Offer  advice  is  discussed  last.  Followup  Responses 
generally  provide  one  of  the  types  of  advice  discussed  above  and 
is  processed  as  an  advice  transaction. 

a.  Accept  Advice/NSN  Notification  Processing.  Two  major 
events  shown  in  Figure  V-3  involved  in  processing  accept  advice 
transactions  and  NSN  Notifications  are  File  Maintenance  and 
Notification  Actions. 

(1)  File  Maintenance.  There  are  eight  subevents 
included  in  this  major  event. 

(a)  Accept  advice  transactions  and  NSN  Notifi¬ 
cations  are  received  by  the  cataloger.  These  items  are  pulled 
from  the  suspense  file  for  processing. 
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(b)  When  the  accept  advice  is  a  final  advice 
or  when  an  NSN  Notification  is  received  for  an  item  new  to  the 
Marine  Corps,  a  catalog  transaction  is  prepared  to  add  Marine 
Corps  peculiar  data  to  DLSC  files. 

(c)  Catalog  transactions  are  forwarded  to 
MCASC  for  input  to  the  Technical  Data  Management  Subsystem. 

(d)  Catalog  transactions  are  automatically 
transmitted  to  DLSC  for  processing. 

(e)  DLSC  approvals  are  forwarded  to  the  cata- 
loger  as  notification. 

(f)  The  cataloger  completes  the  Item  History 
Card  when  DLSC  approvals  are  received,  and  forwards  completed 
cards  to  the  Operations  Office  for  retention. 

(g)  When  items  are  complete,  the  Provisioning 
List  is  retained  by  the  equipment  specialist  and  a  correspondence 
(NSN  Required  List/Followup/etc . , )  file  is  maintained  by  the 
cataloger . 


(h)  The  cataloger  forwards  technical  data  to 
the  Weapons  Sy s t ems / Equ i pmen t  Support  Technical  Data  Branch 
(TDB)  for  retention  in  the  technical  data  repository. 

(2)  Notificaion  Actions.  This  major  event  consists 
of  two  subevents. 


(a)  The  cataloger  monitors  the  completion  of 
items  in  the  provisioning  project  using  the  item  history  cards 
as  a  control  file. 

(b)  When  all  item  history  cards  for  a  provi¬ 
sioning  project  have  been  forwarded  to  the  Operations  Office  for 
retention,  the  provisioner  is  notified  of  completion  of  the  pro¬ 
visioning  project. 

b.  Reject  Advice  Processing.  There  are  three  major 
events  included  in  processing  reject  advice  transactions.  As 
shown  in  Figure  V-4  these  major  events  are  File  Maintenance, 
Advice  Review,  and  File  Maintenance. 

(1)  File  Maintenance.  This  major  event  consists  of 
two  subevents . 

(a)  Reject  advice  transactions  are  received  by 

the  cataloger. 
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(b)  The  cataloger  pulls  the  suspense  file  for 
these  Items  and  updates  the  Item  History  Cards  with  the  reject 
advice. 


(2)  Advice  Review.  This  major  event  consists  of 
three  subevents. 


(a)  Each  item  is  reviewed  to  determine  if  the 
reject  is  based  on  invalid  data  or  improper  support  data  (bad 
IMC)  . 


(b)  New  SSR  transactions  are  generated  for 
validation  rejects,  using  source  data,  for  resubmittal  to  the 
appropriate  IMMs. 


(c)  Support  rejects  are  generally  retained  for 
management  by  the  Marine  Corps  and  the  cataloger  initiates  NSN 
assignment  requests  or  other  appropriate  action  for  these  items. 

(3)  File  Maintenance.  This  major  event  consists  of 
a  single  subevent. 

(a)  Items  for  which  resubmittal  SSR  transac¬ 
tions  were  generated  are  placed  in  the  suspense  file  awaiting 
advice  from  IMMs. 

c.  Offer  Advice  Processing.  There  are  three  major 
events  included  in  processing  offer  advice  transactions.  These 
major  events  are  File  Maintenance,  Advice  Review,  and  File 
Maintenance  . 

(1)  File  Maintenance.  This  major  event  cons'  ts  of 
two  subevents  . 

(a)  Offer  advice  transactions  are  received  by 

the  cataloger. 

(b)  The  cataloger  pulls  each  item  for  which  an 
offer  advice  transaction  is  received  from  the  suspense  file  and 
updates  the  Item  History  Records. 

(2)  Advice  Review.  This  major  event  consists  of 
six  subevents. 

(a)  The  cataloger  reviews  each  offer  using  the 
source  documents,  technical  data  for  the  offered  item,  item 
description,  drawings,  catalog  pages  and  item  spec i f i ca t i ons  . 

(b)  When  the  cataloger  cannot  determine  if  the 
offered  item  should  be  accepted  or  rejected,  he  forwards  the 
item  to  an  equipment  specialist  for  review. 
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(c)  When  the  equipment  specialist  cannot  make 
an  accept/re jec t  determination,  the  item  is  forwarded  to  the 
provlsioner  for  review. 

(d)  The  accept/re ject  decision  is  reached  by 
one  of  these  persons  and  returned  to  the  cataloger. 

(e)  The  cataloger  prepares  an  Offer  Reply  trans 
action  for  each  item  which  received  offer  advice. 

(f)  The  Offer  Reply  transactions  are  mailed  to 
the  appropriate  IMMs. 

(3)  File  Maintenance.  This  major  event  consists  of 
a  single  subevent. 

(a)  Items  requiring  an  NSN  Notification  from 
the  IMM  are  placed  in  the  suspense  file.  The  Item  History  Card 
is  completed  for  other  items  and  is  forwarded  to  the  Operations 
Office  for  retention. 

E.  MARINE  CORPS  INCOMING  SSR  PROCESSING 


Incoming  SSR  processing  at  MCLSBA  is  illustrated  in  Figure 
V-5  in  terms  of  processing  phases  and  major  events.  Subsequent 
to  the  DODSSR  Study  Team  visit  to  this  activity,  incoming  SSR 
processing  was  significantly  altered.  The  discussion  here 
represents  the  altered  processing  as  documented  and  provided  by 
MCLSBA. 

Processing  of  incoming  SSR  transactions  is  shown  in  terms  of 
subevents  and  organizational  elements  in  Figure  V-6. 

Provisioning  and  non p r o vis  ion i ng  SSR  transactions  are  pro¬ 
cessed  identically.  SSR  re submi s s i ons  as  a  result  of  reject 
advice  are  processed  as  initial  submittals  by  MCLSBA.  SSR  change 
submissions  are  rarely  received  by  MCLSBA  and  were  not  specifi¬ 
cally  addressed  during  the  operational  review.  The  Marine  Corps 
generally  accepts  support  only  on  those  Items  which  are  currently 
being  actively  managed  at  MCLSBA;  other  items  are  rejected  to 
the  SICC.  Therefore,  only  NSN  SSR  transactions  are  discussed  in 
this  section. 

1.  SICC  SSR  Processing  Phas<2.  This  processing  phase  occurs 
at  SICC  activities  and  results  in  submission  of  SSR  transactions 
to  MCLSBA  for  processing  as  the  WIMM. 

2.  WIMM  SSR  Processing  Phase.  This  processing  phase  con¬ 
sists  of  eight  major  events  as  shown  in  Figures  V-5  and  V-6. 

These  major  events  are  Catalog  Data  Screen,  Advice  Decision, 

File  Maintenance,  Catalog  Data  Screen,  Catalog  Actions,  Require¬ 
ments  Determination,  Advice  Decision  and  File  Maintenance. 
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a.  Catalog  Data  Screen.  This  major  event  consists  of 
five  subevents  • 

(1)  Incoming  SSR  transactions  are  received  in  the 
Operations  Office  within  the  Supply  Operations  Division  at  MCLSBA. 

(2)  Each  item  received  is  screened  against  the  Master 
Inventory  File  (MIF)  to  extract  requirements  and  user  information. 

(3)  When  screening  indicates  the  item  is  not  in  the 
MIF,  the  item  is  forwarded  to  the  FSC  Cataloger  for  further  screen¬ 
ing.  Items  located  on  the  MIF  continue  processing  as  described 
below,  beginning  with  subsection  2.d.(2). 

(4)  The  FSC  cataloger  screens  each  item  received 
from  the  Operations  Office  against  the  Item  Identification  File 
(IIF).  He  also  screens  each  item  against  DLSC  files. 

(5)  The  FSC  cataloger  reviews  the  screening  results 
for  each  item  to  determine  if  the  NSN  is  valid  and  the  identity 
of  the  current  manager. 

b.  Advice  Decision.  This  major  event  consists  of  two 
subevents . 


(1)  The  FSC  cataloger  determines  from  the  screening 
results  which  items  should  be  rejected  because  the  NSN  is  invalid, 
the  item  is  not  managed  by  the  Marine  Corps,  etc. 

(2)  Items  to  be  rejected  are  returned  to  the  Opera¬ 
tions  Office  for  preparation  of  reject  advice  transactions. 

c.  File  Maintenance.  This  major  event  consists  of  three 
subevents . 

(1)  If  DLSC  screening  results  indicate  the  item  is 
managed  by  the  Marine  Corps,  then  a  file  discrepancy  exists 
between  DLSC  files,  the  Item  Identification  file  and  the  MIF. 

(2)  The  FSC  cataloger  takes  action  to  resolve  these 
file  discrepancies.  File  maintenance  transactions  are  generated 
to  establish  these  items  in  the  Item  Identification  File  and  the 
MIF  as  necessary. 

(3)  These  items  are  then  returned  to  the  Operations 
Office  for  further  processing. 

d.  Catalog  Data  Screen.  This  major  event  consists  of 
th^ee  subevents ■ 
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(1)  Items  returned  from  the  FSC  cataloger,  for  which 
a  file  discrepancy  existed,  are  screened  against  the  MIF  to  ensure 
that  the  item  is  established  on  that  file. 

(2)  The  Operations  Office  next  reviews  each  item  to 
determine  whether  or  not  the  SICC  is  a  registered  user  of  the 
item. 

(3)  When  the  SICC  is  not  registered  as  a  user,  a 
memo  is  prepared  to  the  FSC  cataloger  requesting  that  the  SICC 
be  added  as  a  user  of  the  item  in  DLSC  files. 

e.  Catalog  Actions.  This  major  event  consists  of  five 
subvevents . 


(1)  The  FSC  cataloger  prepares  Add  User  transactions 
to  update  DLSC  files. 

(2)  Add  User  transactions  are  forwarded  to  MCASC. 

(3)  MCASC  inputs  these  transactions  to  the  Techni¬ 
cal  Data  Management  Subsystem  for  transmittal  to  DLSC. 

(4)  DLSC  approvals  are  forwarded  to  the  FSC  cata¬ 
loger. 

(5)  The  approval  is  annotated  on  the  memo  from  the 
Operations  Office  and  returned  for  information  purposes  only. 

f.  Requirements  Determination.  This  major  event  con¬ 
sists  of  two  subevents. 

(1)  The  Operations  Office  forwards  Marine  Corps 
managed  items  to  the  appropriate  item  manager. 

(2 )  The  item  manager  reviews  each  item  forwarded  to 
him  to  determine  the  availability  of  assets  to  meet  SSR  retail 
requirements  . 

g.  Advice  Decision.  This  major  event  consists  of  three 
subevents  as  shoi’n  in  Figure  V-6. 

(1)  Based  on  the  requirements  review  an  ATC  is  as¬ 
signed  each  item. 

(2)  The  ATC  assigned  is  annotated  on  the  SSR  trans¬ 
action. 

(3)  The  SSR  transaction  is  returned  to  the  Opera¬ 
tions  Office. 
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subevents  • 


File  Maintenance.  This  major  event  consists  of  four 


(1)  The  Operations  Office  prepares  accept  advice 
transactions  for  items  returned  from  the  item  manager  and  reject 
advice  transactions  for  items  determined  to  be  rejects  by  the 
FSC  cataloger. 

(2)  These  advice  transactions  are  mailed  to  the 
appropriate  SICCs. 

(3)  The  item  manager  prepares  transactions  to  add 
the  SICC  as  a  user  in  the  MIF.  Items  which  were  assigned  an  ATC 
of  'YE'  have  t^e  retail  quantity  placed  in  the  PRF  to  prevent 
assets  from  being  declared  as  excess  when  they  are  needed  to 
support  SSR  requirements. 

(4)  The  Operations  Office  places  the  original  SSR 
transaction  and  a  copy  of  the  advice  transaction  in  a  manual 
history  file. 

3.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
occurs  at  SICC  activities  which  process  advice  transactions  from 
MCLSBA.  Reject  advice  transactions  may  result  in  a  resubmittal 
of  the  SSR  transaction  to  MCLSBA.  When  advice  is  not  received 
from  MCLSBA,  the  SICC  may  followup  on  the  progress  of  the  SSR 
transactions  submitted.  During  the  operational  review,  these 
followups  took  the  form  of  a  letter,  message  or  telephone  call. 

4.  IMM  Followup  Processing  Phase.  This  processing  phase 
completes  the  processing  cycle  for  incoming  SSR  transactions  at 
MCLSBA.  SSR  resubmittals  are  processed  identically  to  initial 
submittals  discussed  above.  There  is  a  single  major  event  in¬ 
volved  in  processing  followup  transactions. 

a.  File  Maintenance.  This  major  event  consists  of  four 
subevents . 

(L)  All  followups  received  are  referred  to  the 
Operations  Office  for  action. 

(2)  In  the  Operations  Office,  the  followup  is 
matched  to  the  manual  history  file  on  NSN,  DOR,  ISN  and  PCC. 

(3)  When  matching  transactions  are  found  in  the 
history  fiie,  a  duplicate  of  the  advice  transaction  in  the  file 
is  made.  A  letter  indicating  No  Record  of  receipt  of  the  SSR 
transaction  is  prepared  when  the  item  cannot  be  located  in  the 
history  file. 

(4)  The  letter  and/or  advice  transactions  are  mailed 
to  the  SICC.  When  the  followup  is  by  telephone,  the  response  Is 
also  made  via  telephone. 
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CHAPTER  VI 


DEFENSE  LOGISTICS  AGENCY 


A.  INTRODUCTION 


Four  of  the  Defense  Supply  Centers  (DSCs)  under  the  Standard 
Automated  Materiel  Management  System  (SAMMS)  are  the  primary  DLA 
activities  involved  in  SSR  generation  and  processing.  Under  the 
Operational  Implementation  Review  phase  of  research,  two  of  these 
DCSs  were  visited:  the  Defense  Construction  Supply  Center  (DCSC) 
and  the  Defense  Electronics  Supply  Center  (DESC).  DCSC  was 
visited  prior  to  the  implementation  of  the  I  MM  Manual.  This  DCSC 
was  visted  because  it  is  colocated  with  DLA's  System  Design  Activ¬ 
ity  and  provided  a  picture  of  the  manual  steps  involved  in  pro¬ 
cessing  SSR  t r a nsac t i ons  .  DCSC  also  does  provisioning  of  con¬ 
struction  equipment  for  DLA.  DESC  was  visited  because  of  the 
volume  of  business  experienced  and  because  electronics  items 
were  reported  to  be  a  problem  commodity  by  the  Military  Services. 
The  visit  to  DESC  was  made  after  the  implementation  of  the  new 
IMM  Manual.  The  processing  described  in  this  section  is  keyed 
to  the  review  at  DESC,  since  this  review  did  take  place  after  1 
May  1978.  Also,  because  only  a  minima1  amount  of  provisioning 
is  done  by  DLA,  this  Section  describes  DLA  processing  on  a  Cl MM 
basis  only . 

This  Section  first  presents  the  DLA  automated  SSR  operational 
system  used  at  DESC  during  the  implementation  review.  The  orga¬ 
nizational  elements  involved  in  SSR  processing  at  DESC  are  des¬ 
cribed,  followed  by  a  description  of  the  actual  processing  that 
takes  place.  As  in  previous  sections,  the  processing  descrip¬ 
tion  is  given  in  terms  of  phases,  major  events  and  subevents. 

B .  DLA  AUTOMATED  SSR  OPERATIONAL  SYSTEM  DESCRIPTIONS 

1.  Implementation  Status.  The  SAMMS  SSR  Subsystem  was 
designed  and  developed  as  three  independent  applications.  The 
Daily  SSR  Application  processes  active  SSR  items  on  a  daily 
basis.  The  weekly  SSR  Application  provides  for  maintaining  a 
history  file  of  completed  items  and  provides  for  interrogations 
to  this  file  by  the  SICC  through  followup  transactions  and  by 
DSC  personnel  through  file  maintenance  transactions.  The  Monthly 
SSR  Application  provides  for  a  report  of  monthly  activity  in  the 
SSR  Subsystem.  The  SAMMS  SSR  Subsystem  was  implemented  at  all 
the  DSCs  on  1  May  1978,  concurrently  with  implementation  of  the 
IMM  Manual.  During  the  operational  review  at  DESC,  the  study 
team  found  that  the  Daily  SSR  Application  was  scheduled  in  a 
single  job  stream  and  executed  on  a  daily  basis,  Monday  through 
Friday;  the  Weekly  SSR  Application  was  scheduled  separately  and 
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executed  on  Friday  of  each  week,  after  completion  of  the  Daily 
SSR  Application;  and  the  Monthly  SSR  Application  was  scheduled 
separately  and  executed  on  the  last  day  of  each  month,  after 
completion  of  the  Daily  and  Weekly  SSR  Applications. 

2 .  SAMMS  SSR  Subsystem  Processing  Differences 

The  DLA  Automated  SSR  Operational  System  found  at  DESC 
during  the  implementation  review  is  illustrated  in  Figure  VI-1. 
This  Figure  is  almost  identical  to  the  systems  design  overview 
presented  in  Part  1  of  this  Volume;  however,  there  were  two 
significiant  changes  made  to  the  SAMMS  SSR  Subsystem  after  the 
study  team  visit  to  DESC.  These  changes  are  included  in  the 
description  given  in  Part  1  and  are  explained  here  to  preclude 
any  confusion  between  the  processing  descriptions  given  here  as 
opposed  to  those  given  earlier. 


The  first  of  these  changes  involves  initial  SSR  pro¬ 
cessing.  At  the  time  of  the  DESC  visit,  when  SSR  transactions 
were  input  to  the  Daily  SSR  Application,  they  would  be  listed 
on  the  Provisioning  PCC/High  Dollar  Review  List  and  two  sets  of 
cards  would  be  punched.  These  cards  were  identical  to  the  input 
SSR  transactions,  with  the  exception  of  Document  Identifier  Codes 
(DICs).  The  DICs  were  converted  to  a  'YD  '  with  the  third  posi¬ 
tion,  depending  on  the  input  DIC,  as  shown  below: 


Original  PIC 

OWA 

GXA 

CXB 

CXC 

CXF 

CXG 

CXK 


Converted  DIC 

YD  J 
YDM 
YDN 
YDP 
YDS 
YDT 
YDW 


After  review  by  functional  personnel,  the  'YD  'cards  are 
input  to  the  Daily  SSR  Application  for  further  processing. 

The  second  change  involves  the  processing  of  Offer  Reply 
transactions.  At  the  time  of  the  DESC  visit,  the  SSR  Subsystem 
was  not  programmed  to  accept  Offer  Reply  transactions  directly 
from  the  SICC  via  A'fTODIN.  These  transactions  had  to  be  manually 
reviewed  and  converted  to  file  maintenance  transactions  to  accom¬ 
plish  the  same  act. ..ns  described  for  Offer  Reply  transactions  in 
Part  1  of  this  Volume. 
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Figure  VI 


C.  CIMM  ORGANIZATIONAL  STRUCTURE 


The  organizational  elements  involved  in  processing  SSR  trans¬ 
actions  at  DESC  are  shown  in  Figure  VI-2.  There  are  four  direc¬ 
torate  level  organizations  Involved:  the  Directorate  of  Technical 
Operations,  the  Office  of  Data  Systems,  the  Directorate  of  Supply 
Operations  and  the  Directorate  of  Procurement  and  Production. 

Of  these  directorates,  the  Directorate  of  Technical  Operations 
is  the  primary  processing  element. 

1.  Directorate  of  Technical  Operations  (DTP).  There  are 
five  division  level  organizational  elements  within  this  direc¬ 
torate  involved  in  SSR  processing.  These  division  level  elements 
are  shown  in  Figure  VI-2  and  include  the  Provisioning  Control 
Office,  the  Quality  Assurance  Division,  the  Technical  Services 
Division,  the  Cataloging  Division  and  the  Technical  Data  Manage¬ 
ment  Office. 

a.  Provisioning  Control  Office  (PCO).  This  Office  serves 
as  the  central  processing  element  involved  in  SSR  processing.  It 
serves  as  the  overall  monitor  responsible  for  insuring  all  SSR 
transactions  received  are  processed  to  completion  within  the  pro¬ 
cessing  standards  and  procedures  documented  in  the  I  MM  Manual. 

This  Office  also  serves  as  point  of  contact  between  the  DSC  and 
the  SICC  for  routing  of  correspondence,  technical  data  submission, 
return  of  technical  data  for  rejected  items,  etc.  The  PCO  is 
responsible  for  all  inputs  to  the  SSR  Subsystem  including  SSR 
transactions,  followup  transactions,  file  maintenance  transac¬ 
tions  and  local  functional  inquiries;  and  for  processing  of  out¬ 
put  products  received.  A  manual  PCC  History  File  is  maintained 
for  two  years  within  the  PCO,  which  is  responsible  for  notifying 
the  Directorate  of  Supply  Operations  of  SSR  changes  received 
affecting  the  quantities  submitted  on  the  original  SSI  transac¬ 
tions  . 


b .  Quality  Assurance  Division  (QAD) .  This  Division  is 
responsible  for  reviewing  Individual  Repair  Parts  Ordering  Data 
(IRPOD)  items  submitted  as  SSR  items  and  preparing  Special 
Product  Inspection  Requirements  when  necessary.  QAD  is  also 
responsible  for  reviewing  all  SSR  items  submitted  for  special 
packaging/preservat ion  requirements . 

c.  Technical  Services  Division  (TSD).  This  Division 
performs  technical  review  for  new  part  number  SSR  items  falling 
within  certain  FSCs.  This  review  includes  a  characteristics 
analysis  of  the  part  number  submitted,  based  on  a  comparison  of 
the  technical  data  submitted  with  technical  data  locally  avail¬ 
able  for  similar  items.  This  review  is  conducted  to  preclude 
the  stock  listing  of  incomplete  descriptions,  low  reliability 
and  duplicate  items  of  supply. 
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d.  Cataloging  Division.  This  Division  contains  four 
branches.  The  branches  include  three  Item  Identification  Branches 
(IIBs)  and  a  Catalog  Operations  Branch  (COB). 

(1)  Item  Identification  Branches  (IIBs).  The  Item 
Identification  Branches  perform  two  basic  functions  as  part  of 
processing  Part  Number  SSRs.  First,  the  IIBs  perform  technical 
review  for  new  items  not  reviewed  in  the  Technical  Services  Divi¬ 
sion.  The  Item  Identification  Branches  also  prepare  item  iden¬ 
tifications  for  new  items  to  be  submitted  to  DLSC  for  NSN  assign¬ 
ment  . 


(2)  Catalog  Operations  Branch  (COB).  This  Branch 
is  responsible  for  performing  quality  review  of  all  cataloging 
transactions  prior  to  entry  in  SAMMS  for  local  processing  or 
transmittal  to  DLSC  for  processing.  This  branch  also  keypunches 
cataloging  transactions  and  is  responsible  for  correction  of 
errors.  When  new  items  have  NSNs  assigned  by  DLSC,  the  COB 
completes  item  process! rg  by  extracting  technical  data  for  the 
Technical  Data  Management  Office  and  disposing  of  the  remainder 
of  each  item  package. 

e .  Technical  Data  Management  Office  (TDMO) .  This  Office 
is  responsible  for  the  technical  data  repository.  The  TDMO  re¬ 
quests  technical  data  from  manufacturers  when  requests  are  initi¬ 
ated  by  the  PCO  or  IIBs. 

2.  Office  of  Data  Systems  (OPS).  This  Office  is  responsible 
for  implementing  DL A  standard  ADP  Systems  including  SAMMS.  It 
insures  that  interfacing  su bsy s t em/ app 1 ic a t i ons  within  SAMMS  are 
functioning  p-operly.  The  ODS  controls  inputs  to  SAMMS  and  is 
responsible  for  scheduling  and  executing  job  streams,  and  dis¬ 
tributing  outputs  to  the  proper  functional  areas. 

3.  Directorate  of  Supply  Operations  (DSO).  This  Directorate 
receives  SSR  change  transaction  data  and  is  responsible  for  taking 
appropriate  manual  action  to  process  this  data.  The  SSRs  (Condi¬ 
tion  2)  with  the  Nondefinitive  Units  of  Issue  listing  Is  received 
by  this  Directorate,  and  when  the  technical  data  for  these  items 
is  received  from  the  PCO,  it  must  be  included  in  requirements 
computations  processing.  In  addition,  new  items  for  which  supply 
control  studies  are  generated  a^e  processed  in  this  Directorate. 

A .  Directorate  of  Procurement  and  Production  (DPP) .  This 
Directorate  becomes  involved  only  when  procurement  requests  are 
generated  as  a  result  of  SSR  processing  and  is  responsible  for 
processing  these  requests. 
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D. 


INCOMING  SSR  PROCESSING 


The  incoming  SSR  processing  flow  within  DLA  is  based  on 
whether  or  not  the  item  has  an  NSN  assigned.  Items  for  which 
NSNs  have  been  assigned  (active  and  inactive)  are  automatically 
processed  within  the  SAMMS.  Items  which  do  not  have  an  NSN 
assigned  (PSCNs  and  Part  Numbers)  undergo  a  combination  of  auto¬ 
mated  and  manual  processing.  The  processing  flow  for  provision¬ 
ing  and  nonprovisioning  SSR  transactions  is  generally  the  same. 

As  a  result,  incoming  SSR  processing  is  discussed  in  two  seg¬ 
ments.  The  first  segment  handles  SSR  transactions  containing  an 
NSN;  the  second  discusses  SSR  transactions  containing  PSCNs  and 
Part  Numbers . 

Occasionally,  a  Military  Service  will  request  priority  pro¬ 
cessing  of  SSR  transactions  submitted  under  a  specific  PCC.  This 
is  generally  accomplished  via  telephone  followed  by  submittal  of 
the  SSR  transactions.  When  priority  processing  is  requested,  the 
items  in  the  PCC  package  are  processed  as  a  group  rather  than  on 
an  individual  item  by  item  basis.  The  priority  results  in  hand¬ 
carrying  the  entire  package  from  organization  to  organization  for 
immediate  processing.  Automated  processing  is  not  affected  by 
priority  requests. 

There  are  specific  procedures  for  processing  SSR  change  trans¬ 
actions  at  the  DSCs.  These  changes  are  input  to  the  SSR  Subsystem 
with  other  incoming  SSR  transactions  and  are  validated  for  proper 
control  elements  and  packages.  Change  transactions  failing  these 
validations  are  printed  on  the  Provisioning  Input  Exceptions  List. 
Those  that  pass  these  validations  are  printed  on  the  Provisioning 
Design  Change  List.  Superseding  item  changes  continue  automated 
processing  like  an  initial  submission.  All  other  changes  are 
manually  processed.  Manual  processing  generally  consists  of 
notifying  the  Directorate  of  Supply  Operations  of  the  quantity 
changes  by  memorandum.  The  Provisioning  Design  Change  List  is 
filed  in  the  PCC  History  File  with  the  initial  submittals. 

A  procedure  for  following  up  on  technical  data  promised  by 
SICCs  was  found  at  DESC.  It  is  unknown  whether  this  or  a  simi¬ 
lar  procedure  exists  at  other  DSCs.  When  a  part  number  SSR  is 
received  with  a  Date  Technical  Data  to  be  Supplied,  a  3x5  control 
card  is  made  up  for  the  item  and  placed  in  a  suspense  file.  When 
the  technical  data  is  not  received  by  the  date  promised,  the 
technical  library  is  screened  to  determine  if  the  technical  data 
already  exists  at  the  DSC.  If  not,  a  letter  is  prepared  and 
mailed  to  the  SICC  citing  the  item  for  which  data  was  promised 
but  not  received.  If  a  response  to  the  letter  is  not  received 
within  45  days,  the  control  card  is  pulled  from  the  file  and  a 
request  is  forwarded  to  the  Technical  Data  Management  Office  for 
a  complete  screen  of  the  technical  library  for  the  technical 
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data  promised  and,  if  not  found,  to  request  the  data  from  the 
item  manufacturer.  The  control  card  is  then  destroyed.  The 
Technical  Data  Management  Office  prepares  a  DD  Form  1982,  Request 
For  Verification  of  Manufacturers  Part  Number.  A  copy  is  sent 
to  the  manufacturer  and  a  suspense  file  is  established.  After 
60  days,  another  request  is  mailed  to  the  manufacturer  if  no 
reply  has  been  received  for  the  first  request.  After  another  60 
days,  a  copy  of  the  DD  Form  1982  is  annotated  "no  response"  and 
forwarded  to  the  request  originator  (Provisioning  Control  Office 
or  Cataloging  Division).  A  record  of  the  "no  response"  is  also 
maintained  within  the  Technical  Data  Management  Office.  It  is 
important  that  this  process  does  not  delay  processing  of  the  SSR 
transaction  at  DESC.  When  the  technical  data  is  received,  it  is 
stored  in  the  technical  library  and  used  by  the  Cataloging  Divi¬ 
sion  to  upgrade  the  Item  Identification. 

E  •  INCOMING  NSN  SSR  PROCESSING 

The  DLA  Incoming  NSN  SSR  Operational  System  at  DESC  is  shown 
in  Figure  VI-3.  This  system  consists  of  four  phases:  SICC  SSR 

Processing,  IMM  SSR  Processing,  SICC  SSR  Advice  Processing  and 
I  MM  Followup  Processing.  Only  two  of  these  phases  take  place  at 
DESC.  These  two  phases  are  the  IMM  Processing  Phases  which  are 
broken  down  into  major  events  on  the  figure.  The  phases  and 
major  events  from  Figure  VI-3  are  further  divided  into  subevents 
related  to  specific  organizational  elements  in  Figure  VI-4.  The 
following  discussion  is  keyed  to  these  subevents. 

1.  SICC  SSR  Processing  Phase.  In  this  processing  phase, 

SSR  transactions  are  generated  by  SICC  activities  and  mailed 
with  appropriate  technical  data  to  DESC  for  processing. 

2 .  IMM  SSR  Processing  Phase .  This  phase  consists  of  ten 

major  events:  File  Maintenance,  Edit/Validation,  Advice  Deci¬ 

sion,  Method/Level  of  Support,  File  Maintenance,  DLSC  Screening, 
Catalog  Actions,  Advice  Decision,  File  Maintenance  and  Require¬ 
ments  Determination.  Each  is  described  in  terms  of  subevents 
below. 

a.  File  Maintenance.  This  major  event  consists  of  six 
subevents  to  perform  initial  processing  on  incoming  SSR  transac¬ 
tions. 

(1)  SSR  transactions  are  received  at  DESC  by  the 


(2)  The  PCO  separate:  the  SSR  transaction  cards 
from  the  technical  data  and  correspondence  submitted.  The  cards 
are  forwarded  to  ODS  for  initial  automated  processing. 
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Figure  VL 


Deck  from  PCO  and 
Input  to  Daily  SSR 
Application 


Figure  VI-4 


Figure  VI- 


SSR  WORK  F 
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Response  Transactions 
and  Transmit  to  SICC 


(3)  ODS  inputs  the  SSR  transactions  into  the  Daily 
SSR  Application  for  the  production  of  the  converted  DIC  (YD 
cards)  SSR  transactions  and  the  Provisioning  PCC/High  Dollar 
Review  List. 


(4)  The  original  cards,  YD_  cards  and  listing  is 
forwarded  to  the  PCO. 

(5)  The  PCO  marries  the  technical  data  and  corre¬ 
spondence  back  to  each  PCC  package  and  establishes  a  PCC  file 
folder  for  each  package.  The  technical  data  and  correspondence 
are  placed  in  the  folder.  The  original  SSR  transactions  are 
filed  and  retained  indefinitely.  Each  item  on  the  Provisioning 
PCC/High  Dollar  Review  List  is  scanned  for  a  dollar  value  greater 
than  $2,500.  Processing  for  items  exceeding  the  $2,500  limit 

are  suspended  from  further  processing  pending  verification  with 
the  SICC.  This  list  is  placed  in  the  PCC  file  folder. 

(6)  One  deck  of  YD  SSR  transaction  cards  are  for¬ 
warded  to  ODS  for  further  automated  processing.  A  second  deck 
of  YD-  SSR  transaction  cards  are  retained  in  the  PCO  until 
receiving  automated  outputs  from  the  first  deck.  This  second 
card  deck  is  then  destroyed. 

b.  Edit/Validation.  This  major  event  consists  of  five 
subevents  to  accomplish  automated  validation  of  incoming  SSR 
t  ransactions  . 

(1)  The  YD_  card  deck  received  by  ODS  is  input  to 
the  SSR  Subsystem  for  processing. 

(2)  The  SSR  Subsystem  performs  control  element, 
duplicate  transaction  and  package  validations. 

(3)  Errors  encountered  are  output  on  the  Provision¬ 
ing  Input  Exceptions  List.  Automated  processing  for  these  items 
is  terminated.  This  list  is  reviewed  in  the  PCO  and  errors  are 
either  corrected  by  the  PCO  and  re -input  as  YD-  SSR  transactions 
to  the  SSR  Subsystem  or  the  list  is  mailed  to  the  SICC  as  advice 
notification.  Inactive  SSR  items  with  a  nondefinitive  Unit  of 
Issue  are  output  on  the  SSRs  (Condition  2)  with  Nondefinitive 
Units  of  Issue  listing.  This  listing  is  used  by  the  PCO  to  pull 
required  technical  data  submitted  with  the  SSR  transactions  and 
forwards  it  to  the  DSO  for  processing. 

(4)  SSR  change  transactions  are  identified  and  out¬ 
put  on  the  Provisioning  Design  Change  List.  Only  superseding 
change  transactions  continue  automated  processing.  Other  changes 
are  manually  processed  by  the  PC 0  and  the  DSO. 
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(5)  Detail  Data  Element  Validation  is  performed  on 
the  remaining  SSR  transactions. 

c.  Advice  Decision.  This  major  event  consists  of  four 
subevents . 


(1)  SSR  transaction  images  with  detail  data  element 
errors  are  output  to  the  Provisioning  SSR  List  accompanied  by  an 
Action  Taken  Code  (ATC)  from  the  I  MM  Manual  indicating  the 
error. 

(2)  Item  records  for  these  rejected  SSR  transac¬ 
tions  are  built  and  output  to  the  SSR  History  File. 

(3)  Reject  advice  transactions  are  generated  and 
forwarded  to  the  appropriate  SICCs  via  AUTODIN. 

(4)  Control  data  and  associated  ATC  for  rejected 
SSR  transactions  are  output  to  the  Provisioning  Advice  List. 

d.  Method /Level  of  Support.  This  major  event  consists 
of  a  single  subevent  to  determine  an  AAC  based  on  data  contained 
in  the  SSR  transaction. 

(1)  Items  which  pass  validation  have  an  AAC  assigned 
using  data  in  the  SSR  (AAC,  Source  Code,  PCC,  Quantities)  in  con¬ 
junction  with  an  AAC  assignment  filter  and  a  cost  differential 
table. 

e.  File  Maintenance.  This  major  event  consists  of  two 
subevents  . 

(1)  Valid  SSR  items  are  output  on  the  Provisioning 

SSR  List. 

(2)  Item  records  are  structured  for  each  LISSR 
package  and  are  established  on  the  SSR  Suspense  File.  The  pro¬ 
cessing  time  standards  contained  in  the  IMM  Manual  are  started 
at  this  point  in  DLA  processing. 

f.  DLSC  Screening.  This  major  event  consists  of  three 
subevents. 

'I)  DLSC  screening  transactions  are  generated  for 
each  valid  .  item  entering  the  SSR  Suspense  File.  DLSC  screen¬ 
ing  transacts  are  also  generated  for  each  part  number  sub¬ 
mitted  as  an  Ado  ional  Reference  transaction.  These  transac¬ 
tions  are  forwarded  to  DLSC  via  AUTODIN  for  processing. 


\ 
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(2)  Replies  to  DLSC  screening  transactions  are 
received  and  analyzed  by  the  Technical  and  Logistics  Services 
Subsystem  of  SAMMS •  Replies  to  additional  reference  numbers 
submitted  are  output  for  manual  action  by  the  Cataloging  Divi¬ 
sion  for  preparation  of  Add  Reference  Number  Transactions  if 
there  is  no  match. 

(3)  Items  which  matched  to  an  active  NSN  or  inactive 
NSN  in  DLSC  files  are  passed  to  the  SAMMS  Cataloging  Subsystem 
for  further  processing.  Other  replies  are  forwarded  to  the  SSR 
Subsystem. 

g.  Catalog  Actions.  This  major  event  consists  of  two 
subevents. 


(1)  The  Cataloging  Subsystem  analyzes  the  SSR  data 
and  DLSC  data  to  determine  the  appropriate  action.  Transactions 
are  generated  to  record  the  SICC  as  a  user,  upgrade  the  AAC  of 
the  item,  reactivate  the  NSN,  etc.,  as  appropriate  and  transmits 
these  transactions  to  DLSC. 

(2)  Receipt  of  DLSC  approvals  of  these  cataloging 
actions  by  the  Technical  and  Logistics  Services  Subsystem  are 
passed  to  the  SSR  Subsystem  for  processing. 

h.  Advice  Decision.  This  major  event  consists  of  four 
subevents . 

(1)  When  the  DLSC  replies  to  screening  transactions 
are  received  and  analyzed  by  the  Technical  and  Logistics  Services 
Subsystem,  the  ac c e p t / r e j ec t  decision  is  reached.  The  accepts 
are  passed  to  the  Catalog  Subsystem  as  described  above  and  the 
rejects  are  passed  to  the  SSR  Subsystem.  DLSC  approvals  of  cata¬ 
log  action  are  passed  to  the  SSR  Subsystem  also. 

(2)  The  SSR  Subsystem  generates  reject  advice  trans¬ 
actions  based  on  the  decision  reached  in  the  Technical  and  Logis¬ 
tics  Services  Subsystem.  When  DLSC  approvals  are  received  in 

the  SSR  Subsystem,  accept  advice  transactions  are  generated. 

(3)  These  advice  transactions  are  forwarded  to  the 
appropriate  SICCs  via  AUTODIN. 

(4)  Control  data  and  associated  ATC  for  items  for 
which  advice  transactions  are  generated  are  output  to  the  Provi¬ 
sioning  Advice  List. 

i.  File  Maintenance.  This  major  event  consists  of  two 
subevents . 
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(1)  When  advice  transactions  are  generated  and 
transmitted  to  the  SICC,  these  items  are  considered  complete. 
Completed  items  are  transferred  from  the  SSR  Suspense  File  to 
the  SSR  History  File. 

(2)  The  output  listings  from  this  process  include 
the  Provisioning  SSR  List,  the  Provisioning  Advice  List,  the 
Provisioning  Input  Exceptions  List,  the  Provisioning  Design 
Change  List  and  the  SSRs  (Condition  2)  with  Nondefinitive  Units 
of  Issue.  These  listings  become  a  part  of  the  manual  PCC  file 
folder.  The  Provisioning  SSR  List  and  Provisioning  Advice  List 
are  used  primarily  as  a  check  against  the  Provisioning  PCC/High 
Dollar  Review  List  to  insure  all  SSR  transactions  submitted 
complete  processing. 

j.  Requirements  Determination.  This  major  event  con¬ 
sists  of  a  single  subevent  as  shown  in  Figure  VI-4. 

(1)  Items,  which  are  accepted  for  support  and  have 
an  assigned  AAC  indicating  the  item  is  or  should  be  stocked,  are 
passed  to  the  Requirements  Subsystem  for  use  in  the  determination 
and  acquisition  of  requirements. 

3.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
occurs  at  SICC  activities  and  provides  for  processing  of  ccept/ 
reject  advice  transactions  generated  by  DESC.  Reject  adv  i 
transactions  may  result  in  correction  of  the  SSR  transact  n  and 
resubmittal.  When  the  SICC  has  not  received  an  advice  tr  .ctian 
within  35  days  of  SSR  transaction  submittal  the  SIC'  may  g.nerate 
a  followup  transaction  to  inquire  about  the  status  c  f  the  SSR 
transaction.  The  followup  transactions  may  be  mailed  to  DESC  or 
they  may  be  transmitted  via  AUTODIN. 

4.  IMM  Followup  Processing  Phase.  This  processing  ohase 
consists  of  the  single  major  event.  Resubmittals  ar»  processed 
identically  to  initial  submittals  and  are  therefore  not  discussed 
as  a  part  of  this  processing  phase. 

a.  File  Maintenance.  This  major  event  consists  of 
three  subevents  to  accomplish  processing  of  followup  transac¬ 
tions  from  the  SICC. 

(1)  Followup  transactions  submitted  via  AUTODIN  are 
automatically  routed  to  the  SSR  Subsystem.  Those  submitted  by 
mail  are  received  by  the  PCO  and  forwarded  to  ODS  for  input  to 
the  SSR  Subsystem. 

(2)  The  followup  transactions  are  screened  against 
the  SSR  Suspense  File  for  an  item  record  with  matching  control 
elements.  If  a  match  is  not  found,  the  followup  transaction  is 
screened  against  the  SSR  History  File. 
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(3)  Based  on  the  results  of  the  matching  process. 
Followup  Response  transactions  are  generated  and  transmitted  via 
AUTODIN  to  the  appropriate  SICCs.  When  a  match  Is  found  and 
advice  has  already  been  furnished  the  SICC,  the  Followup  Response 
transaction  contains  the  same  advice.  When  a  match  is  found  and 
no  advice  has  been  furnished  the  SICC,  the  Followup  Response  trans 
action  contains  an  ATC  '67'  (advice  pending).  When  no  match  is 
found,  an  ATC  '66'  (no  record)  is  placed  in  the  Followup  Response 
transaction. 

F.  INCOMING  PSCN/ PART  NUMBER  SSR  PROCESSING 


The  DLA  Incoming  PSCN/Part  Number  SSR  Operational  System  at 
DESC  is  shown  in  Figure  VI-5.  This  operational  system  consists 
of  four  phases:  SICC  SSR  Processsing,  IMM  SSR  Processing,  SICC 
SSR  Advice  Processing,  and  IMM  Followup/Offer  Reply  Processing. 
The  IMM  phases  are  those  which  take  place  at  DESC  and  are  broken 
down  into  major  events  in  Figure  VI-5.  These  major  events  are 
subdivided  into  subevents  and  the  organizational  elements  per¬ 
forming  each  subevent  in  Figure  VI-6.  The  discussion  that  fol¬ 
lows  is  keyed  to  these  subevents. 

1 .  SICC  SSR  Processing  Phase.  This  processing  phase  takes 
place  at  SICC  activities  where  SSR  transactions  are  generated 
and  mailed  to  DESC  for  processing. 

2.  IMM  SSR  Processing  Phase.  This  processing  phase  is  made 
up  of  fourteen  major  events:  File  Maintenance,  Edit /Validation , 
Advice  Decision,  Method/Level  of  Support,  File  Maintenance,  DLSC 
Screening,  Advice  Decision,  File  Maintenance,  Advice  Decision, 
File  Maintenance,  Catalog  Actions,  File  Maintenance,  Advice  Deci¬ 
sion,  and  Requirements  Determination.  Each  of  these  major  events 
is  described  in  terms  of  subevents  and  organizational  elements 
below . 


a.  File  Maintenance.  The  six  subevents  within  this 
major  event  are  shown  in  Figure  VI-6.  These  subevents  are  iden¬ 
tical  to  those  discussed  in  Subsection  E.2.a.  above. 

b.  Edit/Validatlon.  The  five  subevents  within  this 
major  event  are  shown  in  Figure  VI-6  and  are  identical  to  those 
discussed  in  Subsection  E.2.b.  above  with  one  difference.  No 
SSRs  (Condition  2)  with  Nondefinitive  Units  of  Issue  listing  are 
produced  for  PSCN/Part  Number  SSR  Transactions. 

c.  Advice  Decision.  The  four  subevents  within  this 
major  event  are  shown  in  Figure  VI-6  and  are  identical  to  those 
discussed  in  Subsection  E.2.c.  above. 
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d.  Method/Level  of  Support.  The  single  subevent  within 
this  major  event  is  shown  in  Figure  VI-6  and  is  identical  to 
that  discussed  in  Subsection  E.2.d.  above. 

e.  File  Maintenance.  The  two  subevents  within  this 
major  event  are  shown  in  Figure  VI-6  and  are  identical  to  those 
discussed  in  Subsection  E.2.e.  above. 

f.  DLSC  Screening.  This  major  event  consists  of  three 
subevents  as  shown  in  Figure  VI-6. 

(1)  The  SSR  Subsystem  generates  DLSC  screening 
transactions  for  AUTODIN  transmittal  to  DLSC  for  all  valid  items 
entering  the  SSR  Suspense  File.  Separate  DLSC  screening  trans¬ 
actions  are  generated  for  additional  reference  numbers  received 
with  each  valid  LISSR  package. 

(2)  DLSC  replies  to  these  screening  transactions 
are  initially  processed  by  the  Technical  and  Logistics  Services 
Subsystem.  This  Subsystem  also  performs  initial  analysis  of 
these  transactions  before  forwarding  them  to  the  SSR  Subsystem. 

(3)  PSCNs  which  matched  to  DLSC  files,  and  Part 
Numbers  which  received  a  No  Match  reply,  are  output  to  the  PCO 
for  manual  processing.  The  output  products  received  for  these 
items  include  three  skeleton  file  maintenance  transactions  per 
item  and  the  Provisioning  Part  Number  Select-NSN  Request  Card 
List. 


g.  Advice  Decision.  This  major  event  consists  of  four 
subevents  as  shown  in  Figure  VI-6. 

(1)  Items  not  having  skeleton  file  maintenance 
transactions  generated  and  not  listed  on  the  Provisioning  Part 
Number  Select-NSN  Request  Card  List  are  rejected  as  a  result  of 
DLSC  screening.  These  items  generally  consist  of  PSCNs  which 
did  not  match  to  DLSC  files,  and  Part  Numbers  (other  than  those 
submitted  as  additional  reference  numbers)  which  matched  to  a 
single  or  multiple  NSNs/  PSCNs  in  DLSC  files. 

(2)  The  SSR  Subsystem  generates  reject  advice  trans¬ 
actions  for  these  items. 

(3)  The  reject  advice  transactions  are  forwarded  to 
the  appropriate  SICCs  via  AUTODIN. 

(4)  Items  for  which  reject  advice  transactions  are 
generated  are  output  to  the  Provisioning  Advice  List  which  serves 
as  a  notification  to  the  PCO  of  item  completion. 
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h.  File  Maintenance.  This  major  event  serves  to  update 
automated  and  manual  files  with  the  results  of  processing  up  to 
this  point  and  to  initiate  manual  processing  on  those  items  for 
which  it  is  required.  Figure  VI-6  shows  this  major  event  is  made 
up  of  ten  subevents. 

(1)  The  SSR  Suspense  File  item  records  are  updated 
with  the  actions  taken  resulting  from  DLSC  replies. 

(2)  Items  for  which  reject  advice  transactions  were 
generated  from  DLSC  replies  are  transferred  to  the  SSR  History 
File  . 

(3)  Output  listings  from  this  processing  which  are 
placed  in  the  PCC  file  folder  include  the  Provisioning  SSR  List, 
the  Provisioning  Input  Exceptions  List,  Provisoning  Design  Change 
List,  the  Provisioning  Part  Number  Select-NSN  Request  Card  List, 
and  the  Provisioning  Advice  List. 

(4)  Items  on  the  Provisioning  Advice  List  containing 
reject  advice  are  identified  and  the  associated  technical  data 
(if  any)  submitted  with  these  items  is  mailed  back  to  the  SICC. 

(5)  Item  file  folders  are  established  by  the  PCO 
for  each  item  on  the  Provisioning  SSR  List  for  which  skeleton 
file  maintenance  transactions  were  automatically  produced.  Each 
item  file  folder  will  contain  the  skeleton  file  maintenance  trans¬ 
actions,  any  technical  data  or  special  instructions  forwarded  by 
the  SICC  and  appropriate  SSR  transaction  data. 

(6)  When  an  item  is  identified  as  an  Individual 
Repair  Parts  Ordering  Data  (IRPOD)  item,  it  is  forwarded  to  the 
Quality  Assurance  Division  (QAD)  for  processing. 

(7)  The  QAD  reviews  each  IRPOD  item  and  prepares 
Special  Product  Inspection  Requirements  when  necessary  and  inserts 
these  requirements  In  the  item  file  folder. 

(8)  The  item  file  folders  are  returned  to  the  PCO 
for  further  processing. 

(9)  The  PCO  splits  the  item  file  folders  into  two 
groups  for  item  entry  control  (1EC)  processing.  One  group  con¬ 
tains  items  having  a  high  potential  for  identification  of  sub¬ 
stitutes.  This  group  is  forwarded  to  the  Technical  Services 
Division  for  an  In-depth  IEC  review  and  generally  consists  of 
resistors,  capacitors,  connectors,  relays,  tubes,  transistors 
and  integrated  circuits.  The  second  group  is  forwarded  to  the 
Item  Identification  Branches  (IIBs)  for  a  less  stringent  IEC 
review . 


(10)  The  technical  review  performed  by  the  Technical 
Services  Division  includes  a  characteristics  review  of  the  tech¬ 
nical  data  submitted  in  conjunction  with  military  specification 
items,  commerlcal  items  and  stock,  listed  items  in  an  effort  to 
determine  if  an  acceptable  or  better  item  can  be  identified.  The 
review  performed  in  the  lIBs  is  basically  a  verification  of  the 
part  number  submitted.  The  review  of  items  in  both  organizational 
elements  is  controlled  by  a  date  stamping  and  log  in/log  out  pro¬ 
cedure  . 


i.  Advice  Decision.  This  major  event  consists  of  eight 
subevents . 

(1)  The  reviews  performed  by  the  Technical  Services 
Division  and  lIBs  result  in  an  advice  decision  of  accept/offer/ 
reject.  Generally,  items  are  rejected  at  this  point  only  if  the 
technical  data  submitted  is  inadequate,  the  Part  Number  or  FSCM 
is  invalid,  or  the  Part  Number/FSCM  combination  is  in  error.  The 
error  condition  is  annotated  on  the  item  file  folder.  Before 
these  file  folders  are  returned  to  the  PCO,  the  technical  data 
(when  adequate)  is  sent  to  the  Technical  Data  Management  Office 
(TDMO)  for  duplication.  When  a  substitute  item  'is  identified 
and  an  offer  is  to  made,  a  Standard/Alternate  Item  Referral  (DLA 
Form  5A6)  is  prepared  and  placed  in  the  item  file  folder.  Other 
items  are  simply  accepted  for  support  and  this  acceptance  is 
annotated  on  the  item  file  folder.  One  skeleton  file  maintenance 
transaction  for  accepted  items  and  items  for  which  an  offer  is  to 
be  made  is  retained  by  the  division  performing  the  review  as  a 
part  number  history  file  for  future  use. 

(2)  When  the  review  is  completed,  the  item  file 
folders  are  returned  to  the  PCO. 

(3)  The  PCO  completes  skeleton  file  maintenance 
transactions  for  automated  processing  and  forwards  them  to  ODS. 

(4)  The  PCO  mails  hard  copy  documentation  including 
tehnical  data  (when  required)  and  DLA  Form  546s  for  offered  items, 
and  original  technical  data  for  rejected  items,  to  the  SICC. 

(5)  The  final  skeleton  file  maintenance  transaction 
for  rejected  items  is  placed  in  the  PCC  file  folder.  Item  file 
folders  for  offered  items  are  placed  in  a  suspense  file  awaiting 
an  offer  reply  from  the  SICC.  Item  file  folders  for  accepted 
items  are  forwarded  to  the  Cataloging  Division  (CD)  for  further 
processi ng. 

(6)  ODS  inputs  the  completed  file  maintenance  trans¬ 
actions  into  the  SSR  Subsystem. 
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(7)  The  SSR  Subsystem  generates  advice  transactions 
for  AUTODIN  transmittal  to  the  SICC. 

(8)  The  advice  transactions  are  transmitted  to  the 
appropriate  SICCs  and  the  items  for  which  advice  is  provided  are 
output  on  the  Provisioning  SSR  List.  When  an  initial  advice  has 
not  been  furnished  the  SICC  after  residing  on  the  SSR  Suspense 
File  for  25  days,  the  SSR  Subsystem  automatically  generates  and 
transmits  an  advice  transaction  containing  ATC  '67'  (advice 
pending)  to  the  SICC. 

j.  File  Maintenance.  This  major  event  consists  of  three 
subevents . 

(1)  The  item  records  on  the  SSR  Suspense  File  are 
updated  with  the  advice  manually  determined.  When  an  offer 
advice  is  returned  to  the  SICC,  a  special  suspense  is  set  up  in 
the  item  record.  When  an  offer  reply  is  not  received  within  30 
days,  the  item  is  printed  on  the  Provisioning  30-Day  Followup 
for  XL/YQ  Advice  listing.  After  45  days  with  no  reply,  the 
item  is  printed  on  the  Provisioning  45-Day  Followup  for  YL/YQ 
Advice  listing.  After  60  days  with  no  reply  received,  the  item 
is  printed  on  the  Provisioning  60  Day-Reject  YL/YQ  Advice  listing 
and  a  reject  advice  transactions  containing  ATC  '08'  (no  reply 

to  offer)  is  generated  and  transmitted  to  the  SICC. 

(2)  Item  records  for  which  reject  advice  transac¬ 
tions  are  generated  are  transferred  to  the  SSR  History  File. 

(3)  The  Provisioning  Advice  List  and  the  Provision¬ 
ing  60  Day  Reject  YL/YQ  Advice  list  are  placed  in  the  PCC  File 
Folder.  One  copy  of  the  Provisioning  30  Day  Followup  for  YL/YQ 
Advice  list  and  the  Provisioning  45  Day  Followup  for  YL/YQ  Advice 
list  is  placed  in  the  item  file  folder.  A  second  copy  of  these 
lists  is  mailed  to  the  SICC. 

k.  Catalog  Actions.  This  major  event  consists  of  seven 
subevents  . 


(1)  The  Item  Identification  Branch  (IIB)  sets  up  an 
internal  control  file  for  each  item  file  folder  received. 

(2)  A  fully  descriptive  Item  Identification  (II)  is 
prepared  whenever  possible  using  the  appropriate  Federal  Item 
Identification  Guide  (FIIG)  and  technical  data.  When  this  is 

not  possible,  a  lesser  II  is  prepared  and  a  Request  for  Verifica¬ 
tion  of  Manufacturers  Part  Number  (DD  Form  1982)  is  prepared 
requesting  technical  data  from  the  manufacturer.  The  DD  Form 
1982  is  forwarded  to  the  Technical  Data  Management  Office  (TMDO) 
for  processing. 
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(3)  The  Item  file  folders  containing  the  I  Is  are 
returned  to  the  PCO. 

(4)  The  PCO  clears  the  suspense  on  these  items  and 
they  are  forwarded  to  the  Catalog  Operations  Branch  (COB)  for 
processing. 

(5)  The  COB  performs  a  quality  review  of  each  II. 
Errors  found  are  returned  to  the  appropriate  IIB  for  correction 
and  return. 

(6)  Item  file  folders  for  IIs  passing  quality  review 
are  placed  in  a  suspense  file  awaiting  NSN  assignment  from  DLSC. 

(7)  II  transactions  are  forwarded  to  ODS  for  input 
to  the  Cataloging  Subsystem  and  transmittal  to  DLSC. 

1.  File  Maintenance.  This  major  event  consists  of  ten 
subevents  . 

(1)  DLSC  replies  are  received  and  initially  pro¬ 
cessed  in  the  Technical  and  Logistics  Services  Subsystem. 

(2)  NSN  assignments  are  forwarded  to  the  SSR  Sub¬ 
system  for  processing. 

(3)  The  SSR  Subsystem  updates  the  item  record  in 
the  SSR  Suspense  File  with  the  assigned  NSN. 

(4)  NSN  assignments  and  other  replies  to  NSN  requests 
are  output  to  the  COB  for  processing. 

(5)  When  the  DLSC  reply  indicates  the  item  was 
matched  to  a  single  or  multiple  NSNs  during  characteristics 
screening  as  part  of  the  NSN  assignment  process,  the  NSNs  matched 
are  placed  in  the  item  file  folder.  These  item  file  folders  are 
returned  to  the  PCO  for  processing. 

(6)  The  COB  reviews  DLSC  replies  for  NSN  assign¬ 
ments  and  pulls  the  item  file  folders  for  these  replies  from  the 
suspense  file. 

(7)  When  the  NSN  "'■'g..  ">  t  is  for  an  IRPOD  item, 

the  item  file  folder  is  forwai..  to  the  TSD. 

(8)  Non-IRPOD  items  are  forwarded  to  the  Quality 
Assurance  Division  (QAD)  for  review. 

(9)  After  PPB  review,  the  item  file  folders  are 
returned  to  COB  to  determine  if  the  II  can  be  upgraded.  If  so, 
the  folders  are  forwarded  to  the  appropriate  IIB. 


(10)  The  technical  data  from  remaining  item  file 
folders  is  forwarded  to  the  technical  data  repository  for  storing 
and  the  folder  is  destroyed. 

m.  Advice  Decision.  This  major  event  consists  of  seven 
subevents . 

(1)  Item  file  folders  returned  to  the  PCO  are  re¬ 
viewed  to  determine  if  the  characteristics  screening  at  DLSC 
resulted  in  a  match  to  a  single  or  to  multiple  NSNs.  When  mul¬ 
tiple  NSNs  were  matched  the  PCO  confers  with  TSD  and  IIB  person¬ 
nel  to  determine  if  one  of  these  NSNs  is  the  same  item  as  the 
part  number  submitted. 

(2)  File  maintenance  transactions  are  prepared  for 
exact  NSN  matches  from  characteristics  screening  and  for  the 
single  NSN  selected  from  multiple  NSN  matches.  These  file  main¬ 
tenance  transactions  are  forwarded  to  ODS  for  input  to  the  SSR 
Subsy s  tem . 


(3)  When  the  PCO,  in  conjunction  with  TSD  and  IIB 
personnel,  determine  that  none  of  the  NSNs  returned  by  DLSC  are 
the  same  item  as  that  submitted,  the  item  file  folder  is  returned 
to  COB  for  resubmittal  of  the  NSN  request. 

(4)  ODS  inputs  file  maintenance  transactions,  for¬ 
warded  by  the  PCO,  to  the  SSR  Subsystem. 

(5)  The  SSR  Subsystem  updates  the  SSR  Suspense  File 
with  the  matched  NSN  and  generates  NSN  Notifications  for  these 
items  and  items  for  which  an  NSN  assignment  was  returned  by  DLSC. 


(6)  The  NSN  Notifications  are  transmitted  to  the 
appropriate  SICCs  via  AUTODIN. 

(7)  Once  the  NSN  Notifications  have  been  generated, 
these  item  records  are  considered  complete  and  are  printed  on 
the  Provisioning  Advice  List  and  transferred  to  the  SSR  History 
File.  The  Provisioning  Advice  List  is  placed  in  the  PCC  File 
Folder  by  fhe  PCO  and  item  file  folders  are  destroyed. 

n.  Requirements  Determination.  This  major  event  con¬ 
sists  of  a  single  subevent. 

(1)  The  SSR  Subsystem  passes  SSR  quantities  to  the 
Requirements  Subsystem  when  the  NSN  Notifications  are  generated. 
These  quantities  are  used  in  the  requirements  subsystem  to  pro¬ 
duce  supply  control  studies  and  procurement  requests  for  new 
items  and  for  recomputations  of  existing  items. 
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3.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
occurs  at  SICC  activities  and  processes  advice  transactions  gener¬ 
ated  by  DESC.  When  the  SICC  has  not  received  advice  for  an  SSR 
transaction  within  35  days  or  NSN  Notification  within  70  days 

the  SICC  may  generate  a  followup  transaction  to  obtain  the  pro¬ 
cessing  status  of  the  item.  These  followup  transactions  may  be 
mailed  or  transmitted  via  AUTODIN  to  DESC.  Reject  advice  trans¬ 
actions  may  result  in  a  resubmission  of  the  corrected  SSR  trans¬ 
actions.  These  must  be  mailed  and  are  treated  as  initial  sub¬ 
missions  by  DESC.  Offer  advice  transactions  require  review  and 
preparation  of  Offer  Reply  transactions  by  the  SICC.  The  Offer 
Reply  transactions  indicate  acceptance  or  rejection  of  the 
offered  item  and  may  be  mailed  or  transmitted  via  AUTODIN. 

4.  IMM  Followup/Offer  Reply  Processing  Phase.  This  pro¬ 
cessing  phase  consists  of  the  single  major  event  shown  in  Figure 
VI-5. 

a.  File  Maintenance.  This  major  event  consists  of  12 
subevents  as  shown  in  Figure  VI-6. 

(1)  This  subevent  is  identical  to  that  discussed  in 

subsection  E.4.a.(l). 

(2)  This  subevent  is  identical  to  that  discussed  in 

subsection  E.4.a.(2). 

(3)  This  subevent  is  identical  to  that  discussed  in 

subsection  E.4.a.(3). 

(4)  The  SSR  Subsystem  automatically  generates  out¬ 
put  listings  that  serves  as  followup  or  notifications  to  the  PCO 
of  the  status  of  items  on  the  SSR  Suspense  File.  These  listings 
are  Parts  I,  II  and  III  of  the  Provisioning  Control  File  Aging 
Report  . 

(5)  The  PCO  uses  these  listings  to  monitor  the  pro¬ 
gress  of  items  and  to  generate  followups  to  the  Technical  Services 
Division  and  Cataloging  Division  as  necessary. 

(6)  Offer  Reply  transactions  are  received  by  the 
PCO  for  processing.  Those  transmitted  via  AUTODIN  are  rejected 
out  of  SAMMS  and  forwarded  to  the  PCO. 

(7)  The  PCO  prepares  file  maintenance  transactions 
that  can  be  mechanically  processed  from  the  Offer  Reply  transac¬ 
tions.  These  file  maintenance  transactions  are  forwarded  to 
ODS.  The  Offer  Reply  transactions  are  placed  in  the  appropriate 
item  file  folders. 
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(8)  ODS  inputs  the  file  maintenance  transactions  to 
the  SSR  Subsystem. 

(9)  The  SSR  Subsystem  updates  the  item  records  on 
the  SSR  Suspense  File  to  reflect  the  acceptance  or  rejection  of 
the  offered  items. 

(10)  When  an  NSN  offer  is  accepted,  the  item  record 
is  processed  identically  to  an  NSN  SSR  transaction  subsequent  to 
validation,  as  described  starring  with  Subsection  E.2.f.  above. 

(11)  When  a  Part  Number  offer  is  accepted  by  the  SICC 
or  the  offered  item  is  rejected,  new  skeleton  file  maintenance 
transactions  are  generated  and  the  items  are  listed  on  a  new 
Provisioning  Part  Number  Select-NSN  Request  Card  List.  These 
output  products  are  forwarded  to  the  PCO  for  processing. 

(12)  The  PCO  pulls  the  item  file  folders  for  these 
items  from  the  suspense  file  and  forwards  them  to  the  11 B  for 
preparation  of  11s  to  be  forwarded  to  DLSC  for  NSN  assignment. 
This  processing  is  described  above  beginning  with  Subsection 
F  .  2  .  k  . 


CHAPTER  VII 


GENERAL  SERVICES  ADMINISTRATION 


A.  INTRODUCTION 


The  Federal  Supply  Service  (FSS)  Is  t.  he  SSR  processing  agent 
within  t h e  General  Services  Administration  (GSA).  The  FSS  was 
visited  during  the  Operational  Implementation  Review  phase  of 
research  to  review  the  implementation  of  the  I  MM  Manual  within 
GSA.  GSA  acts  as  a  C  T  M M  on  1 v ,  and  therefore,  processes  only 
incoming  commodity  oriented  consumable  SSR  transactions. 

This  Chapter  pres-nt  s  the  automated  system  in  use  at  the 
time  o  t  t  lit*  ■>  p  r  a  t  i  cm  I  review,  the  organizational  elements  with¬ 
in  the  FSS  i  trvii  1  ved  in  the  processing  of  incoming  SSR  t  r  a  n  s  a  c  - 
lions  and  1  i>'M  K  ,r;i,  rss  iip;  operational  systems.  Active  NSN 
SSR  t  rdns.i.  t  i  s  ,  hurt  i  ve  NSN/ P  SON  SSR  transactions  and  Part 
Number  SSR  trio  i  or.  s  each  constitute  a  separate  operational 

system  in  t  !.  .  >  r  e  i  .  Within  each  operational  system,  there 

gene  ra  i  1  >  :  ■  .  !  i  *.  t  •  ••  (ion  made  between  provisioning  and  non- 

pro  v  i  s  i  on  i  :t »  '  ■»  !■'  t  >  i  •:  s  .  c  t  i  on  processing,  and  each  operational 

system  a  p  p  1  i  •  .  r  pi.il  1  v  to  hath.  Since  no  specific  procedures 
were  developed  >r  ;>r>.  easing  SSR  change  transactions,  they  are 
n o  t  addressed  i ;  t  h i <  C h a  p  t  e  r . 

B  .  GSA  A  U  T  0 1 1  ATE  D  ( )J>  K  R  AT  1  t )  N  A  L_  S',’  S  TF  M  DESCRIPTION 

1  .  j_m  p_l  eme  n  c  a  t  i  ini  Statu;.  The  automated  Logistics  Data 
Management  (LDM)  lysti m  described  in  Part  1  of  this  Volume  was 
in  the  design  stag*.'  of  development  during  both  the  systems  and 
operational  review  phases  .-(  the  D'UiSSK  Study.  The  automated 

operational  system  in  use  bv  GSA  during  the  operational  review 

is  termed  the  Master  Reference  and  Management  Data  System  (MRMDS). 
Upon  implementation  of  the  LDM  System,  the  M  R  M  0  S  w i i l  no  longer 
be  used  by  GSA.  An  overview  of  MRMDS  is  given  below. 

2 .  MRMDS  Overview.  Die  basic  elements  of  MRMDS  relating  to 

SSR  processing  a  re  shown  i  n  Figure  VII-!. 

a.  Inputs.  There  are  two  sources  of  SSR  related  inputs 
to  MRMDS.  The  first  of  these  is  manually  generated  inputs. 

These  functional  inputs  consist  of  inquiries  and  file  updates. 

The  results  from  DI.SC  .are  also  input  to  MRMDS.  DI.  SC  inputs  in¬ 
clude  screening  replies,  NIIN  assignments  and  other  related  trans¬ 
actions. 
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b .  Files  .  There  are  two  files  used  in  SSR  processing 
in  MRMDS.  These  are  the  Master  Data  File  (MDF)  and  the  Catalog 
Action  Master  File  (CAMF).  The  MDF  is  a  sequential  magnetic  tape 
file  used  for  screening  NSN  SSR  transactions  received.  The  CAMF 
is  also  a  sequential  magnetic  tape  file,  which  contains  a  record 
of  all  cataloging  transactions  submitted  to  DLSC  and  part  number 
SSR  items  under  process.  SSR  items  are  not  entered  directly  to 
the  CAMF  and  are  not  in  the  standard  IMM  Manual  formats.  The 
MDF  serves  as  a  repository  of  items  managed  by  GSA,  while  the 
primary  function  of  the  CAMF  is  as  a  suspense/control  file. 

c.  Processing  .  SSR  processing  within  MRMDS  generally 
consists  of  screening  NSN  SSR  items  against  the  MDF  and  maintain¬ 
ing  processing  control  using  the  CAMF.  DLSC  screening  transac¬ 
tions  and  NUN  requests  are  posted  to  the  CAMF  for  suspense. 

When  a  DLSC  reply  is  not  received  within  60  days,  the  item  is 
dropped  from  the  CAMF.  Automated  generation  of  DLSC  followup 
transactions  is  not  a  feature  of  this  system.  SSR  items  which 
have  been  on  the  CAMF  for  more  than  12  days  are  printed  on  an 
overdue  list  each  cycle  until  completed  (advice  is  mailed  to  the 
SICC). 

d.  Outputs.  Functional  outputs  from  this  system,  re¬ 
lated  to  SSR  processing,  include  MDF  inquiry  results,  DLSC 
screening  replies  and  NIIN  assignments  from  DLSC  in  addition  to 
the  Overdue  List  mentioned  above. 

C .  IMM  ORGANIZATIONAL  STRUCTURE 

The  organizational  elements  performing  CIMM  SSR  processing 
functions  by  GSA  are  shown  in  Figure  V 1 1 - 2 .  As  shown  by  this 
figure,  there  are  two  organizations  under  the  Administrator  in¬ 
volved  in  SSR  processing.  The  first  of  these  is  the  Federal 
Supply  Service  which  is  the  primary  processing  organization. 

The  Region  3  Administrator  comes  into  play  because  the  FSS  does 
not  maintain  its  own  computer  facility.  The  Region  3  Administra¬ 
tor,  which  is  in  the  same  geographical  area  as  (not  colocated 
with)  the  FSS,  provides  computer  operations  support  to  execute 
MRMDS  . 

1.  Office  of  Customer  Service  and  Support.  This  Office 
within  the  FSS  consists  of  eight  divisions.  One  of  these  divi¬ 
sions,  the  Logistics  Data  Management  Division,  is  responsible  for 
receiving  and  processing  SSR  transactions  within  GSA. 

a.  Logistics  Data  Management  Division  (LDMD).  This 
Division  consists  of  three  branches.  The  Data  Management  Branch 
and  the  Item  Identification  Branch  perform  SSR  related  functions. 


(1)  Data  Management  Branch  (DMB).  There  are  three 
organizational  entities  within  the  Data  Management  Branch  in¬ 
volved  involved  in  SSR  processing:  the  Supply  Support  Section, 
the  Supply  Management  Section,  and  the  PCAM  Room. 

(a)  The  Supply  Support  Section  consists  of  SSR 
technicians  and  is  where  SSR  transactions  are  initially  received 
in  GSA.  The  SSR  technician  is  responsible  for  monitoring  the 
processing  progress  of  all  SSR  transactions  received.  All  fol¬ 
lowup  transactions  are  processed  by  the  SSR  technician  and  all 
advice  transactions  and  Followup  Response  transactions  are  for¬ 
warded  to  the  SICC  by  this  Section.  The  SSR  technician  performs 
initial  validation  on  SSR  transactions  received  and  is  responsible 
for  maintaining  manual  control,  suspense  and  history  files  for 
these  transactions.  Catalog  data  screening  of  automated  files 
may  also  be  initiated  in  this  Section. 

(b)  The  Supply  Management  Section  consists  of 
cataloging  personnel  who  generally  receive  SSRs  and  determine 
the  AAC  to  be  assigned  each  SSR  item.  Catalogers  also  perform 
validation  on  selected  SSR  data  elements  for  part  number  SSR 
items.  The  cataloger  also  prepares  catalog  management  data  trans¬ 
actions  required  for  NSN  a s s i g nmen t / r e a c t i va t i on . 

( c )  The  Punched  Card  Accounting  Machine  (PCAM) 
Room  produces  the  actual  advice  and  Followup  Response  transac¬ 
tions  to  be  forwarded  to  the  SICCs  when  initiated  by  an  SSR  tech¬ 
nician.  The  PCAM  Room  also  produces  listings  of  incoming  SSR 
transactions,  advice  transactions  and  processing  worksheets. 

(2)  Item  Identification  Branch  (IIB).  The  IIB  is 
responsible  for  preparing  NUN  requests  for  transmittal  to  DLSC 
and  transactions  to  reactivate  inactive  NSNs.  The  item  entry 
control  function  for  part  number  SSR  items  is  performed  in  this 
Branch  and  may  result  in  the  identification  of  substitute  items 
to  be  offered  to  SICCs.  The  IIB  may  generate  DLSC  screening 
transactions  as  part  of  the  item  entry  control  process.  The  GSA 
technical  data  repository  is  located  in  this  Branch,  and  this 
Branch  is  responsible  for  its  maintenance. 

2.  Office  of  Procurement.  Each  SSR  item  accepted  for  sup¬ 
port  by  GSA  is  forwarded  to  this  Office  as  the  final  processing 
step.  This  Office  generally  reviews  each  item  and  forwards  the 
item  to  the  Regional  Office  responsible  for  managing  the  item. 

At  the  Regional  Office  the  assigned  AAC  is  reviewed  and  the 
actual  level  of  support  is  determined. 
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D.  GSA  INCOMING  CIMM  ACTIVE  NSN  SSR  PROCESSING 


The  GSA  Active  NSN  Operational  System  is  depicted  in  Figure 
VII-3.  As  shown  by  this  figure,  the  operational  system  consists 
of  four  processing  phases;  SICC  SSR  Processing,  IMM  SSR  Processing, 
SICC  SSR  Advice  Processing,  and  IMM  Fo 1 1 o wu p / 0 f f e r  Reply  Pro¬ 
cessing.  The  two  phases  performed  by  GSA  are  those  involving  IMM 
processing;  and  these  phases  are  broken  down  into  major  events 
in  Figure  VII-3.  There  is  no  processing  priority  within  this 
system;  and  the  system  applies  equally  to  incoming  provisioning 
and  no n p r o v i s i o n i ng  SSR  transactions.  The  subevents  and  related 
organizational  elements  within  each  of  the  major  events  and  phases 
in  Figure  VII-3  are  shown  in  Figure  V 1 1 -  4 .  The  discussion  that 
follows  is  keyed  to  these  subevents. 

1.  SICC  SSR  Processing  Phase.  T.iis  processing  phase  occurs 
at  SICC  activities  and  results  in  SSR  transactions  being  sub¬ 
mitted  to  GSA  for  processing. 

2.  IMM  SSR  Processing  Phase.  This  processing  phase  con¬ 
sists  of  nine  major  events:  Edit/Validation,  Advice  Decision, 

File  Maintenance,  Catalog  Data  Screen,  Advice  Decision,  Method/ 
Level  of  Support,  Catalog  Actions,  File  Maintenance  and  DLSC 
Screen. 


a.  Edit/ Validation.  This  major  event  consists  of  two 

subevents - 


(1)  SSR  transactions  are  received  by  an  SSR  tech¬ 
nician  within  the  Data  Management  Branch. 

(2)  The  SSR  technician  validates  the  SSR  transac¬ 
tions  received  for  proper  package  content  and  each  item  is  vali¬ 
dated  to  ensure  the  FSC  is  within  a  GSA  assigned  class.  Other 
data  elements  are  given  cursory  validation. 

b.  Advice  Decision.  This  major  event  consists  of  four 
subevents . 


(1)  When  validation  errors  are  encountered,  reject 
advice  to  be  returned  to  the  SICC  is  annotated  on  the  LISSR 
transaction. 

(2)  SSR  packages  containing  a  single  item  found  in 
error  have  reject  advice  transactions  and  an  advice  list  pro¬ 
duced  by  the  Punched  Card  Accounting  Machine  (PCAM)  Room. 
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GSA  ACTIVE  NSjN  SSR  OPERATIONAL  SYSTEM 


Figure  VII- 


Figure  VII-4 


Transactions 


(3)  The  advice  list  and  original  SSR  transactions 
are  filed  in  manual  history  files  and  retained  for  two  years. 

The  advice  transactions  are  mailed  to  the  S I C  C . 

( 4 )  Items  co  n t  a i i  i n  g  multiple  errors  from  S  S  R  pack¬ 
ages  are  placed  in  a  manual  suspense  file  awaiting  c  ompletion  o  f 
the  remainder  of  the  items  in  the  S  S  R  package.  Generally,  G  S  A 
provides  advice  on  a  PG'C  package  basis  rather  than  on  an  individ 
u  a  1  item  basis. 

c.  File  Maintenance  .  This  major  event  consists  of  five 
subevents . 

(1)  Multiple  item  SSR  packages  are  logged  in  a 
manual  control  file.  The  SSR  processing  time  standards  from  the 
I  MM  Manual  begin  when  the  SSR  package  is  logged  in  this  manual 
control  file. 


(  2 )  The  SSR  technician  forwards  valid  SSR  transac¬ 
tions  to  the  I' GAM  Room  for  processing. 


(3) 
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actions  and  lists  are  re  turned  to  the  SSR  technician. 

(  3  )  Tli  e  SSR  t  e  c  si  n  i  c  i  a  :i  1  i  1  e  s  the  original  SSR  t  r  a  n  s 

actions  in  a  history  fi  le  a  1  >ng  with,  one  copy  of  the  PGC  pacsage 

list. 

d.  Catalog  Data  Screen.  This  ni:ij"i  event  consists  of 
six  s  u  b  t  -  v e n  t s  . 

(1)  The  SSR  technician  forwards  MDF  inquiry  trans¬ 
actions  t  c.  the  Region  3  o  f  f  j  c  e  t  or  process  i  n  g  .  The  Region  3 

0  f  t'  i  c  e  inputs  the  inquiry  t  r  a  u  s  i  c  t  i  o  a  s  to  M  R  M  D  S  . 

'  2  )  M  1)  K  i  a  i,  u  i  r  ••  results  t  n.r  M  KMDS  are  forwarded  to 

the  SSR  t  e  .•  !i  n  i  i  inn. 

(  1  i  !'h  c  S  >  I 
a  \'o  Mat  c  h  i  .  ■  n  <1  i  t  i  .  ■  c.  oc  . 
s  c  r  c  e  •;  !  a  g  t  n;is  ic  t  ion  . 

(  »  )  i 1 1 .  S  ■'  s  r  .  .  a  i  u  •  r.i  a  s  i.-t  ions  are  forwarded  to 


t  c .  hit  i  c  i  an  r  i-  views  these  results.  When 
•:  r  s  ,  tin-  SSR  t  .•  c  I:  n  i  e  i  a  n  generates  a  DISC 
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(5)  DLSC  screening  transactions  are  Input  to  MRMDS 
wt  ?.  Ley  are  placed  on  the  CAMF  for  suspense  and  forwarded  to 
DLSC  r  processing. 

(6)  DLSC  screening  results  are  returned  to  the  SSR 
technician  through  MRMDS  after  the  CAMF  suspense  is  closed. 

e.  Advice  Decision.  This  major  event  consists  of  five 
subevents . 


(1)  MDF  and  DLSC  screening  results  are  received  and 
reviewed  by  the  SSR  technician.  Based  on  this  review,  the  SSR 
technician  makes  the  accept /of fer /re jec t  advice  decision.  Gener¬ 
ally,  items  are  rejected  when  the  NSN  submitted  is  invalid;  sub¬ 
stitute  items  are  offered  when  the  submitted  NSN  is  nonstandard. 
GSA  policy  provides  that  only  NSN  items  will  be  offered  as  sub¬ 
stitute  items . 

(2)  The  SSR  technician  forwards  the  screening 
results  and  SSR  data  to  a  cataloger  within  the  Data  Management 
Branch  for  further  processing. 

(3)  The  advice  determined  by  the  SSR  technician  and 
other  applicable  data  (e.g.,  the  substitute  item  to  be  offered) 
is  annotated  on  each  SSR  transaction  control  card,  then  each 
card  is  placed  in  the  manual  suspense  file  with  the  other  items 
awaiting  completion  of  the  PCC  package. 

(4)  When  the  PCC  package  is  complete,  or  when  25 
days  have  passed  since  entry  of  the  PCC  package  in  the  control 
log,  the  PCC  package  is  forwarded  to  the  PCAM  Room  where  advice 
transactions  are  generated  along  with  an  advice  list. 

(5)  The  SSR  technician  mails  the  advice  transac¬ 
tions  to  the  appropriate  SICC  and  places  the  advice  list  in  a 
manual  history  file  for  two  year  retention. 

f.  Method/Level  of  Support.  This  major  event  consists 
of  two  subevents. 

(1)  The  cataloger  reviews  the  AAC  assignment  for 
each  item  and  updates  the  AAC  when  necessary. 

(2)  Each  item  is  returned  to  the  SSR  technician 
after  review. 

g.  Catalog  Actions.  This  major  event  consists  of  four 
subevents  . 
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(1)  The  SSR  technician  reviews  the  recorded  user 
information  and  the  assigned  AAC  when  items  are  returned  fron 
the  cataloger.  The  advice  for  these  items  may  be  changed  when 
the  AAC  is  changed  by  the  cataloger. 

(2)  Add  User  transactions  are  generated  to  add  the 
S1CC  as  a  user  in  DLSC  and  GSA  files.  In  addition,  when  the  SSR 
package  is  complete  (accepted  items  are  not  considered  complete 
until  this  point),  it  is  forwarded  to  the  PCAM  Room  for  genera¬ 
tion  of  advice  transactions  and  an  advice  list. 

(3)  The  Add  User  transactions  are  forwarded  to  the 
Region  3  Office  for  automated  updating  of  GSA  and  DLSC  files. 

(4)  Advice  transactions  are  mailed  to  the  SICC. 

The  advice  list  is  placed  in  the  two-year  manual  history  file. 

h.  File  Maintenance.  This  major  event  consists  of  two 
subevents . 

(1)  The  Region  3  Office  inputs  the  Add  User  trans¬ 
actions  to  MRMDS  where  they  are  posted  to  the  CAMF  for  suspense 
and  forwarded  to  DLSC  via  AUTODIN.  DLSC  updates  the  DIDSTIR  file 
and  broadcasts  the  change  which,  in  turn,  updates  the  MDF  and 
clears  the  CAMF  suspense. 

(2)  The  DLSC  approval  of  the  transactions  is 
returned  to  the  SSR  technician. 

i.  DLSC  Screen.  This  major  event  consists  of  five  sub¬ 
events  . 

(1)  DLSC  screening  transactions  are  generated  for 
each  item  accepted  for  support. 

(2)  These  transactions  are  forwarded  to  the  Region 
3  Office  by  the  SSR  technician. 

(3)  The  Region  3  Office  inputs  these  transactions 

to  MRMDS  where  they  are  posted  to  the  CAMF  for  suspense  and  trans¬ 
mitted  to  DLSC  by  AUTODIN.  DLSC  screens  these  items  against  DIDS 
files  and  returns  catalog  data. 

(4)  MRMDS  receives  DLSC  screening  responses,  clears 
the  suspense  from  the  CAMF  and  prints  the  catalog  data  returned. 
The  Region  3  Office  forwards  this  data  to  the  SSR  technician. 

(5)  The  SSR  technician  forwards  the  DLSC  cataloging 
data  and  SSR  data  to  the  Office  of  Procurement. 


3.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
occurs  at  SICC  activities.  The  SICC  activities  process  the  advice 
transactions  generated  by  GSA.  The  SICC  activity  may  generate 
followup  transactions  when  advice  is  not  received  from  GSA.  SICC 
activities  are  required  to  generate  Offer  Reply  transactions  to 
inform  GSA  of  acceptance  or  rejection  of  the  offered  item. 

4.  IMM  Followup/Offer  Reply  Processing  Phase.  This  pro¬ 
cessing  phase  consists  of  five  major  events  as  shown  in  figure 
VII-3.  These  major  events  include  File  Maintenance,  Method/Level 
of  Support,  Catalog  Actions,  File  Maintenance  and  DLSC  Screen. 
Resubmittals  from  SICCs  are  treated  as  initial  submissions  by 
GSA,  and  thus,  are  not  addressed  separately. 

a.  File  Maintenance.  This  major  event  consists  of  five 
subevents  as  shown  in  Figure  VII-4. 

(1)  Followup  transactions  are  received  by  the  SSR 
technician.  The  SSR  technician  checks  the  Advice  List  History 
File  first  to  determine  if  advice  has  already  been  furnished  the 
SICC.  If  not  found,  the  active  suspense  file  is  checked  to 
determine  if  the  item  is  still  under  process. 

(2)  The  SSR  technician  annotates  the  advice  from 
the  advice  list,  providing  pending  advice  when  the  item  is  still 
under  process,  or  ATC  '36'  (other)  when  the  item  is  not  found  on 
the  followup  transaction.  Followup  Response  transactions  are 
then  generated  by  the  PCAM  Room  and  forwarded  to  the  SSR  tech¬ 
nician. 


(3)  The  SSR  technician  mails  the  Followup  Response 
transactions  to  the  SICC. 

(4)  The  followup  transactions  are  retained  for  about 
one  month  by  the  SSR  technician,  after  which  they  are  destroyed. 

(5)  Offer  Reply  transactions  received  by  the  SSR 
technician  are  matched  to  the  suspense  file.  The  original  item 
matched  is  extracted  from  the  suspense  file  for  further  pro¬ 
cessing.  When  an  Offer  Reply  is  not  received  within  60  days  of 
the  Date  of  Advice  (DOA),  a  reject  advice  transaction  is  gener¬ 
ated  and  mailed  to  the  SICC. 

b.  Method/Level  of  Support.  This  major  event  consists 
of  two  subevents.  The  discussion  of  these  subevents  is  iden¬ 
tical  to  that  in  Subsection  D.2.f.  above.  This  processing  is 
performed  on  the  original  item  when  the  Offer  Reply  indicates 
reject  or  on  the  offered  item  when  the  Offer  Reply  indicates 
accept . 
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c.  Catalog  Actions.  This  major  event  consists  of  three 
subevents  as  discussed  in  Subsection  D.2.g.  above.  This  pro¬ 
cessing  is  performed  on  the  original  item  when  the  offered  item 
is  rejected  or  on  the  offered  item  when  accepted.  No  advice 
transactions  are  generated  in  this  case. 

d.  File  Maintenance.  This  major  event  consists  of  two 
subevents  as  discussed  in  Subsection  D.2.h.  above.  This  pro¬ 
cessing  is  performed  on  the  original  item  when  the  offered  item 
is  rejected  or  on  the  offered  item  when  accepted. 

e.  DLSC  Screen.  This  major  event  consists  of  five  major 
events  as  discussed  in  Subsection  D.2.i.  above.  This  processing 
is  performed  on  the  original  item  when  the  offered  item  is  re¬ 
jected  or  on  the  offered  item  when  accepted. 

E .  GSA  INCOMING  CIMM  INACTIVE  NSN/PSCN  SSR  PROCESSING 

The  GSA  Inactive  NSN/PSCN  Operational  System  is  shown  in 
Figure  VII-5.  This  operational  system  consists  of  four  processing 
phases:  SIC  SSR  Processing,  IMM  SSR  Processing,  SICC  SSR  Advice 
Processing,  and  IMM  Fol lo wu p / Of f e r  Reply  Processing.  The  IMM  SSR 
Processing  Phase  and  the  IMM  Followup/Offer  Reply  Processing  Phase 
are  broken  down  into  major  events  in  Figure  VII-5.  These  phases 
and  major  events  are  further  broken  down  into  subevents  and  the 
organizational  elements  performing  each  subevent  in  Figure  VII-6. 
The  discussion  of  GSA  Inactive  NSN/PSCN  processing  is  keyed  to 
these  subevents  and  organizational  elements. 

1.  SICC  SSR  Processing  Phase.  This  processing  phase  takes 
place  at  SICC  activities  where  SSR  transactions  are  generated 
and  mailed  to  GSA  for  processing. 

2.  IMM  SSR  Processing  Phase.  This  processing  phase  is  per¬ 
formed  by  GSA  and  consists  of  ten  major  everts:  Ed  it / Val idat ion , 
Advice  Decision,  File  Maintenance,  Catalog  Data  Screen,  Edit/ 
Validation,  Advice  Decision,  Method/Level  of  Support,  Catalog 
Actions,  File  Maintenance  and  DLSC  Screen. 

a.  Edit/Validation.  This  major  event  consists  of  two 
subevents  as  discussed  in  Subsection  D.2.a.  above. 

b.  Advice  Decision.  This  major  event  consists  of  four 
subevents  as  discussed  in  Subsection  D.2.b.  above. 

c.  File  Maintenance.  This  major  event  consists  of  five 
subevents  as  discussed  in  Subsection  D.2.c.  above. 

d.  Catalog  Data  Screen.  This  major  event  consists  of 
six  subevents  as  discussed  in  Subsection  D.2.d.  above. 
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Figure  VII 


Figure  VII-6 


Figure  VII-6 
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(2)  Forward  each  Item 
to  I  IB 


Figure  VII-6 


Figure  VII- 


e.  Edit/Validation.  This  major  event  consists  of  three 
subevents  as  shown  in  Figure  VII-6. 

(1)  The  SSR  technician  reviews  the  MDF  and  DLSC 
screening  results. 

(2)  The  Part  Number(s)  and  manuf ac turer (s )  are 
extracted  from  the  screening  results  for  further  research. 

(3)  The  SSR  technician  contacts  each  manufacturer 
and  verifies  that  the  part  number  is  valid  and  that  the  item  is 
currently  being  manufactured. 

f.  Advice  Decision.  This  major  event  consists  of  five 
subevents  as  discussed  in  Subsection  D.2.e.  above. 

g.  Method/Level  of  Support.  This  major  event  consists 
of  two  subevents. 

(1)  The  cataloger  reviews  each  item  forwarded  by 
the  SSR  technician  and  based  on  the  screening  results  and  SSR 
transaction  data  determines  the  AAC  for  the  item. 

(2)  The  AAC  is  annotated  on  the  SSR  transaction 
control  card. 

h.  Catalog  Actions.  This  major  event  consists  of  four 
subevents . 


(1)  The  cataloger  next  prepares  the  catalog  manage¬ 
ment  data  transactions  required  by  DLSC  to  reactivate  NSNs  or 
activate  PSC Ns . 

(2)  These  items  along  with  the  DLSC  catalog  trans¬ 
actions  are  forwarded  to  the  Item  Identification  Branch  (IIB) 
for  further  processing. 

(3)  The  IIB  prepares  the  remainder  of  the  transac¬ 
tions  required  to  reactivate  NSNs  or  activate  PSCNs. 

(4)  These  transactions  are  forwarded  to  the  Region 
3  Office  for  automated  processing  and  the  SSR  item  is  placed  in 
a  manual  suspense  file. 

(i)  File  Maintenance.  This  major  event  consists  of 
eight  subevents. 

(1)  The  Region  3  Office  inputs  the  transactions  to 
MRMDS  where  the  item  is  established  in  the  MDF.  DLSC  catalog 
transactions  are  posted  to  the  CAMF  and  transmitted  to  DLSC  via 
AUTODIN. 
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(2)  DLSC  reactives  the  NSN  or  activates  the  PSCN 
and  assigns  an  NSN.  This  is  returned  to  MRMDS. 

(3)  MRMDS  updates  the  CAMF  and  MDF  and  lists  the 
approvals  and  assigned  NSNs  .  These  are  forwarded  by  the  Region 
3  Office  back  to  the  1IB. 

(4)  The  IIB  pulls  each  item  from  the  manual  suspense 
file  and  forwards  them  along  with  the  assigned  NSN  and  AAC  to  the 
SSR  technician. 

(5)  The  SSR  technician  in  turn  pulls  the  item  from 
the  suspense  file  and  determines  the  ATC  to  be  returned  to  the 
SICC  and  annotates  it  on  the  SSR  transaction  control  card. 

(6)  When  the  PCC  package  is  complete  or  25  days 
have  passed  from  entry  of  the  SSR  package  in  the  control  log, 
the  PCC  package  is  passed  to  the  PCAM  Room  where  advice  transac- 
tions/NSN  notifications  are  generated. 

(7)  The  SSR  technician  mails  the  advice  transac- 
tions/NSN  notification  to  the  SICC. 

(8)  The  advice  list  produced  by  the  PCAM  Room  is 
filed  in  the  two-year  manual  history  file. 

j.  DLSC  Screen.  This  major  event  consists  of  five 
subevents  as  discussed  in  Subsection  D.2.I.  above. 

3.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
occurs  at  SICC  activities  and  involves  processing  of  advice  trans¬ 
actions  received  from  GSA.  The  SICC  may  generate  resubmittals 

for  rejected  SSR  transactions  or  the  SICC  may  generate  followup 
transactions  when  advice  is  not  received  within  the  time  standards 
given  in  the  IMM  Manual.  The  SICC  is  required  to  respond  to  offer 
advices  furnished  by  GSA  to  indicate  acceptance  or  rejection  of 
the  offered  item. 

4.  IMM  Followup/Offer  Reply  Processing  Phase.  This  pro¬ 
cessing  phase  consists  of  seven  major  events  as  shown  by  Figure 
VII-5.  These  major  events  include  File  Maintenance,  Edit/Valida¬ 
tion,  Advice  Decision,  Method/Level  of  Support,  Catalog  Actions, 
File  Maintenance  and  DLSC  Screen.  Resubmittals  are  processed 
identically  to  initial  submittals  discussed  above.  Processing 

of  followup  transactions  is  described  in  Subsection  D.4.a.  above. 
Offer  Reply  processing  is  dependent  on  whether  the  offered  item 
is  accepted  or  rejected.  Offered  items  accepted  are  processed 
as  an  active  NSN  SSR  submission  as  described  in  Subsections 
D .  2 .  f .  through  D.2.i.  above,  with  the  exception  that  no  advice 
transactions  are  generated  for  these  items.  When  the  offered 
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item  is  rejected,  processing  on  the  original  item  picks  up  where 
the  substitute  item  was  identified  and  is  described  in  Subsec¬ 
tions  E.2.e.  through  E.2.j.  above. 

F .  GSA  INCOMING  CIMM  PART  NUMBER  SSR  PROCESSING 

The  GSA  Part  Number  Operational  System  is  depicted  in  Figure 
VII-7.  As  shown  in  the  figure,  this  operational  system  consists 
of  four  phases  including  the  SICC  SSR  Processing  Phase,  the  IMM 
SSR  Processing  Phase,  the  SICC  SSR  Advice  Processing  Phase,  and 
the  IMM  Followup/Offer  Reply  Processing  Phase.  The  IMM  SSR  Pro¬ 
cessing  Phase  and  the  IMM  Fo 1 lo wu p / Of f e r  Reply  Processing  Phase 
are  performed  by  GSA  and  are  broken  down  into  major  events  in 
Figure  VII-7.  These  phases  and  major  events  are  further  divided 
into  subevents  and  organizational  elements  in  Figure  VII-8. 

1.  SICC  SSR  Processing  Phase.  This  processing  phase  occurs 
at  SICC  activities  and  results  in  SSR  transactions  being  sub¬ 
mitted  to  GSA  for  processing. 

2.  IMM  SSR  Processing  Phase.  This  processing  phase  con¬ 
sists  of  twelve  major  events:  Ed i t / Va 1 i d a t i on ,  Advice  Decision, 
File  Maintenance,  Edit/  Validation,  Advice  Decision,  Method/Level 
of  Support,  Catalog  Actions,  Catalog  Data  Screen,  Advice  Decision 
Catalog  Actions,  File  Maintenance,  and  DLSC  Screen. 

a.  Edit/Validation.  This  major  event  consists  of  two 
subevents . 

(1)  SSR  transactions  are  received  in  the  Data  Manage 
ment  Branch  by  an  SSR  technician. 

(2)  The  SSR  technician  validates  the  SSR  transac¬ 
tions  received  for  proper  package  content.  Each  item  is  vali¬ 
dated  to  ensure  It  ia  within  a  GSA  assigned  FSC  and  other  data 
elements  are  given  a  cursory  examination.  Each  item  Is  checked 
to  determine  if  technical  data  is  submitted  for  the  item.  The 
technical  data  is  examined  to  see  if  the  PCC,  DOR,  ISN  and  ACF 
are  properly  annotated. 

b.  Advice  Decision.  This  major  event  consists  of  four 
subevents  as  discussed  in  Subsection  D.2.b.  above. 

c.  File  Maintenance.  This  major  event  consists  of  ten 
subevents  as  shown  in  Figure  VII-8. 

(1)  Multiple  item  SSR  packages  are  logged  in  a 
manual  control  file. 

(2)  The  SSR  technician  forwards  valid  SSR  transac¬ 
tions  to  the  PCAM  Room. 
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Figure  VII- 


Figure  VII-8 


(2)  Forward  Item  to 
I  IB  for  Process 


Figure  VI 1-8 


(2)  Annotate  Assigned  NSN 
on  Worksheet 


Figure  VII-8 


Offer  Reply 


(3)  The  PDSSR  transaction  is  reformatted.  In  addi¬ 
tion,  SSR  control  cards  and  worksheets  are  prepared  for  each  part 
number  item.  Five  duplicate  control  cards  are  produced  for  each 
item.  These  control  cards  are  essentially  a  duplicate  of  the  SSR 
transaction  with  internal  GSA  data  added.  Four  copies  of  the 
worksheet  is  produced  for  each  item.  These  cards  and  worksheets 
are  the  basis  for  further  processing  and  are  used  as  control  and 
suspense  documents  while  the  item  is  still  active. 

(4)  The  original  SSR  transactions,  control  cards  and 
worksheets  are  returned  to  the  SSR  technician. 

(5)  The  SSR  technician  files  the  original  SSR  trans¬ 
action  in  a  manual  history  file. 

(6)  The  SSR  technician  then  assigns  a  GSA  Document 
Serial  Control  Number  (DSCN)  for  control  purposes  and  annotates 
it  on  the  worksheet. 

(7)  Each  item  is  then  checked  to  see  if  technical 
data  was  submitted  or  not.  The  worksheet  is  annotated  to  indi¬ 
cate  whether  or  not  technical  data  was  submitted. 

(8)  The  SSR  technician  then  generates  transactions 
to  load  each  part  number  item  into  the  CAMF  for  suspense. 

(9)  These  transactions  are  forwarded  to  the  Region 
3  Office  for  automated  processing.  The  item  is  forwarded  to  a 
cataloger  within  the  Data  Management  Branch. 

(10)  The  Region  3  Office  enters  the  transactions  for¬ 
warded  by  the  SSR  technician  into  MRMDS  where  the  item  is  posted 
to  the  CAMF  with  a  12-day  suspense.  After  12  days  the  item 
appears  on  an  overdue  list  until  the  CAMF  suspense  is  cleared. 

d.  Edit/Validation.  This  major  event  consists  of  a 
single  subevent. 

(1)  The  cataloger  validates  specific  data  elements 
for  each  item  before  processing  can  continue.  These  data  ele¬ 
ments  include  Unit  of  Issue,  Unit  Price,  Shelf  Life,  Retail 
Quantity  and  Replenishment  Quantity. 

e.  Advice  Decision.  This  major  event  consists  of  two 
subevents . 


(1)  When  an  error  is  encountered  by  the  cataloger, 
the  error  is  annotated  on  the  worksheet  and  the  item  is  returned 
to  the  SSR  technician. 
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(2)  The  SSR  technician  annotates  reject  advice  on 
the  SSR  transaction  control  card  and  places  it  in  the  manual 
suspense  file. 

f.  Method/Level  of  Support.  This  major  event  consists 
of  two  subevents. 

(1)  The  cataloger  determines  the  AAC  for  each  item 
passing  validation.  For  provisioning  SSRs  generally  AAC  'J' 
(centrally  managed,  and  nonstocked)  is  assigned.  For  nonprovi¬ 
sioning  SSRs  either  AAC  'J'  or  'L’  (purchase  locally)  is  assigned. 

(2)  The  assigned  AAC  is  annotated  on  the  worksheet. 

g.  Catalog  Actions.  This  major  event  consists  of  two 
subevents  . 

(1)  The  cataloger  next  prepares  cataloging  transac¬ 
tions  containing  catalog  management  data.  These  transactions 
are  required  by  DLSC  for  NUN  assignment. 

(2)  The  cataloger  forwards  each  item  to  the  Item 
Identification  Branch  (IIB)  for  further  processing. 

h.  Catalog  Data  Screening.  This  major  event  consists 
of  four  subevents. 

(1)  The  IIB  generates  transactions  to  update  the 
CAMF  for  each  part  number  item  received.  The  IIB  screens  each 
part  number  received  against  the  MCRL  and  other  manually  avail¬ 
able  catalogs  to  determine  if  an  NSN  has  already  been  assigned 
the  item.  An  alternate  item  with  an  NSN  may  be  identified  during 
the  manual  screen. 

(2)  When  a  possible  match  to  an  existing  NSN  is 
found,  a  DLSC  screening  transaction  for  the  NSN  is  generated. 

(3)  These  screening  transactions  are  forwarded  to 
the  Region  3  Office  for  further  processing. 

(4)  The  Region  3  Office  inputs  these  transactions 
to  MRMDS  where  they  are  posted  to  the  CAMF  and  forwarded  to 
DLSC.  DLSC  replies  clear  the  suspense  in  the  CAMF  and  are  out¬ 
put  and  forwarded  to  the  IIB. 

i.  Advice  Decision.  This  major  event  consists  of  five 
subevents . 

(1)  The  IIB  reviews  the  DLSC  screening  results  to 
determine  if  the  existing  item  is  to  be  offered  the  SICC. 


494 


V 


(2)  If  so,  the  NSN  to  be  offered  is  annotated  on  the 
item  worksheet  and  the  item  is  returned  to  the  SSR  technician. 

(3)  The  SSR  technician  annotates  the  NSN  and  offer 
advice  on  a  SSR  control  card  and  places  the  card  in  the  suspense 
file. 

(4)  If  the  PCC  package  is  complete,  or  25  days  have 
passed  since  the  PCC  package  was  logged  in  the  control  file,  the 
SSR  transaction  control  cards  are  forwarded  to  the  PCAM  Room  for 
generation  of  advice  transactions. 

(5)  The  SSR  technician  mails  advice  transactions  to 
the  SICC  and  files  the  Advice  List  in  a  manual  history  file  for 
two-year  retention. 

j.  Catalog  Actions.  This  major  event  consists  of  four 
subevents  . 

(1)  For  items  not  identified  to  an  existing  NSN, 

NIIN  request  transactions  are  prepared  by  the  IIB. 

(2)  The  NIIN  request  transactions  are  forwarded  to 
the  Region  3  Office.  The  IIB  places  the  item  in  suspense  await¬ 
ing  the  NIIN  assignment  by  DLSC. 

(3)  The  Region  3  Office  inputs  the  NIIN  request 
transactions  to  MRMDS  where  they  are  posted  to  the  CAMF  for 
suspense  and  forwarded  to  DLSC. 

(4)  DLSC  returns  the  NSN  assigned  to  MRMDS  where 
the  CAMF  suspense  is  cleared  and  the  NSN  is  output  to  the  IIB. 

k.  File  Maintenance.  This  major  event  consists  of 
eight  subevents. 

(1)  The  IIB  pulls  the  item  from  the  suspense  file 
when  the  NSN  is  received  from  DLSC. 

(2)  The  assigned  NSN  is  annotated  on  the  item 

worksheet . 

(3)  Two  aperture  cards  are  produced  for  those  items 
submitted  with  technical  data. 

(4)  One  aperture  card  is  filed  in  the  technical 
repository  located  within  the  IIB. 

(5)  The  item  and  the  second  aperture  card  are  for¬ 
warded  to  the  SSR  technician. 
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(6)  The  SSR  technician  updates  the  manual  suspense 
file  when  each  item  is  returned  by  the  IIB. 

(7)  When  the  PCC  package  is  complete  or  25  days  have 
passed  since  entrance  of  the  PCC  package  into  the  control  file, 
the  SSR  package  is  forwarded  to  the  PCAM  Room  for  generation  of 
advice  transactions,  NSN  Notifications  and  an  Advice  List. 

(8)  The  advice  transactions  and  NSN  Notification 
are  mailed  to  the  SICC  and  the  Advice  List  is  filed  in  the 
history  file. 

1.  DLSC  Screen.  This  major  event  consists  of  five 
subevents  as  discussed  in  Subsection  D.2.i.  above. 

3.  SICC  SSR  Advice  Processing  Phase.  This  processing  phase 
is  described  in  subsection  D.3.  above. 

4.  IMM  Fo 1 lowup/ Of f e r  Reply  Processing  Phase.  This  pro¬ 
cessing  phase  consists  of  five  major  events.  These  major  events 
include  File  Maintenance,  Method/Level  of  Support,  Catalog  Ac¬ 
tions,  File  Maintenance,  and  DLSC  Screen.  Resubmittals  are  pro¬ 
cessed  as  initial  submittals  discussed  above.  Followup  transac¬ 
tion  processing  is  described  in  Subsection  D.4.a.  above.  Offer 
reply  transactions  indicating  acceptance  of  the  offered  item  are 
processed  as  active  NSNs  described  in  Subsections  D.2.f.  through 
D.2.i.  above,  with  the  exception  that  no  advice  transactions  are 
generated  for  these  items.  Offer  reply  transactions  indicating 
rejection  of  the  offered  item  require  preparation  of  NUN  requests 
as  described  in  Subsections  F.2.j.  through  F.2.1.  above. 
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CHAPTER  VIII 


NIMSR  PROCESSING 


A.  INTRODUCTION 


Within  the  Supply  Support  Concept  discussed  in  Volume  I,  the 
method  of  management  determination  mav  indicate  management  for  a 
nonconsumable  item  under  the  Lead  ICP  concept.  The  procedure 
for  obtaining  support  for  these  items  is  contained  in  the  Joint 
Regulation  for  Elimination  of  Duplication  of  Management  of  Non¬ 
consumable  Items  (Appendix  D,  Reference  2).  This  joint  regula¬ 
tion  contains  a  specific  format  for  submission  of  these  items  as 
shown  in  Figure  VIII-1.  Blocks  1  through  18  on  this  form  are 
manually  completed  by  the  submitter  to  request  support  for  a 
particular  nonconsumable  item.  Blocks  19  through  28  are  manually 
completed  by  the  Lead  ICP  and  returned  to  the  submitter  as  advice. 
All  of  the  Services  use  NIMSRs;  however,  the  generation  and  pro¬ 
cessing  of  these  NIMSRs  from  an  organizational  standpoint  differ. 
Processing  by  each  of  the  Services  is  discussed  below  on  an  orga¬ 
nizational  basis.  Since,  in  each  case,  the  particular  organiza¬ 
tional  elements  themselves  have  already  been  discussed  in  the 
respective  SSR  generation  and  processing  sections,  a  discussion 
of  the  organizational  elements  is  not  repeated  here. 

B .  OUTGOING  NIMSR  PROCESSING 

1 .  Army 


Within  the  Army,  NIMSR  origination  at  TSARCOM  is  by  the 
FSC  cataloger.  The  FSC  cataloger  completes  blocks  1,  3,  4,  3, 
and  10  of  the  NIMSR  form  and  forwards  it  to  the  Data  Management 
Branch.  The  Data  Management  Branch  (DMB)  receives  and  maintains 
a  record  of  all  outgoing  NIMSR  requests.  The  DMB  forwards  the 
NIMSR  forms  to  the  appropriate  item  manager  for  completion  (blocks 
2,  6,  7,  8,  9,  and  11  through  18).  The  item  manager  returns  the 
completed  NIMSR  forms  to  the  DMB  where  they  are  forwarded  to  the 
appropriate  Lead  ICPs  after  a  30-day  suspense  is  established. 

When  a  reply  is  received  from  the  Lead  ICP,  the  DMB 
clears  the  suspense  and  furnishes  a  completed  form  to  the  origi¬ 
nating  FSC  cataloger  and  item  manager.  The  DMB  monitors  local 
files  to  insure  the  Lead  ICP  has  taken  appropriate  action  to 
add  TSARCOM  as  a  SICA  on  each  item. 


SAMPLE  NDCR 


5b.  AF/HlAC 


5c.  navy  oog  code 


16.  INITIAL  QUANTITY  I  7.  DATE  REQUIRED 


8.  LEVEL  G?  SUPPORT 


11.  SHIP  TO 


9.  MANAGEMENT  LEVEL 


10.  MX  RULE 


12.  APPLICATION 


13.  SYSTEMS  SUPPORTED  j  14.  ILSTAIUSD  QUANTITY 


16.  OPERATIONAL  USAGE 


19.  PICA  RESPONDING  OFFICE 


17.  12  MONTH 


15.  TYPE 


18.  UNSERVICEABLE  RETURNS 


OF  SUPPORT 


22.  DATE  FUNDS  ESQUIRED  j  23.  ASSET  AVAILABILITY  DATE  24.  UNIT  CDST 


25.  TOTAL  DOLLAR  VALUE 


28.  UNSERVTCABLE  RECEIVING  ACTIVITY 


Source:  Attachable  *  to  AFL®  400-21 


Figure  VUI-1 
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2 .  Navy 


At  SPCC,  NIMSRS  are  originated  by  a  cataloger  within  the 
Data  Control  Division  for  HME&O  items  or  by  the  provisioner  for 
electronics  items*  The  NIMSRs  in  each  case  are  completed  as  a 
joint  action  between  the  provisioner  and  the  Data  Control  Divi¬ 
sion.  The  cataloger  generally  completes  blocks  1,  3,  4,  5,  and 
10  of  the  form,  while  the  provisioner  completes  blocks  2,  6,  7, 

8,  9,  and  11  through  18.  The  Data  Control  Division  forwards  com¬ 
pleted  NIMSRs  to  the  appropriate  Lead  ICP  and  maintains  a  record 
of  submitted  NIMSRs.  NIMSRs  are  used  in  the  Navy  on  both  an 
intraservice  and  interservice  basis. 

When  the  NIMSRs  are  returned,  the  Data  Control  Division 
reviews  each  NIMSR.  Approved  NIMSRs  are  forwarded  to  the  appro¬ 
priate  item  manager.  The  Data  Control  Division  takes  action  on 
nonapproved  NIMSRs  to  come  to  a  support  agreement  with  the  Lead 
ICP. 


3.  Air  Force.  NIMSRs  are  originated,  completed,  forwarded 
to  the  Lead  ICP,  and  monitored  until  approval  by  the  item  man¬ 
ager  in  the  Air  Force.  No  other  organizational  element  is  in¬ 
volved  in  NIMSR  generation  and  processing  at  the  ALCs.  NIMSRs 
are  used  on  an  Interservice  basis  only  in  the  Air  Force. 

4 .  Marine  Corps 

NIMSRs  are  originated  in  the  Technical  Operations  Divi- 
at  MCLSBA.  The  Technical  Operations  Division  completes  blocks 
1,  2,  3,  4,  5,  10,  and  12.  The  remainder  of  the  form  (blocks  6, 
7,  8,  9,  11,  13,  14,  15,  16,  17,  and  18)  is  completed  by  an  item 
manager  in  the  Supply  Operations  Division.  The  Technical  Opera¬ 
tions  Division  then  forwards  the  NIMSRs  to  the  appropriate  Lead 
Service.  The  Technical  Operations  Division  maintains  a  suspense 
file  on  submitted  NIMSRs  and  will  followup  after  30  days  when  a 
reply  is  not  received. 

When  approved  NIMSRs  are  received  by  the  Technical  Opera¬ 
tions  Division,  the  item  manager  Is  notified  of  the  approval. 

C.  INCOMING  NIMSR  PROCESSING 

1 .  Army .  NIMSRs  forwarded  to  TSARCOM  as  the  Lead  ICP  are 
received  in  the  Data  Management  Branch  where  local  file  inquiries 
are  generated  and  reviewed  to  determine  the  PICA  of  the  item. 

When  TSARCOM  is  the  PICA,  the  NIMSR  forms  are  forwarded  to  the 
Item  manager.  The  item  manager  completes  blocks  19  through  29 
and  returns  the  forms  to  the  Data  Management  Branch.  The  Data 
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Management  Branch  forwards  the  completed  NIMSRs  to  the  FSC  cata- 
loger  for  catalog  action.  When  returned  from  the  FSC  cataloger, 
the  Data  Management  Branch  malls  the  completed  NIMSRs  to  the 
originating  activity  and  monitors  local  files  to  verify  proper 
cataloging  action  has  been  performed. 

2.  Navy .  NIMSRs  are  received  in  the  Data  Control  Division 
where  the  submitted  item  is  screened  against  DLSC  files  to  verify 
SPCC  as  the  PICA.  The  NIMSRs  are  then  forwarded  to  the  appro¬ 
priate  item  manager  for  completion.  The  item  manager  reviews 
each  NIMSR  and  completes  blocks  19  through  29.  The  forms  are 
then  returned  to  the  Data  Control  Division.  The  Data  Control 
Division  returns  completed  NIMSRs  to  the  submitting  activity  and 
takes  appropriate  cataloging  action  to  register  the  submitting 
activity  as  a  SICA  when  necessary. 

3.  Air  Force.  Similarly  to  outgoing  NIMSR  processing,  all 
incoming  NIMSR  processing,  including  catalog  actions  to  CASO , 
are  performed  by  an  item  manager  at  the  ALCs . 

4.  Marine  Corps .  NIMSRs  are  received  by  an  item  manager 
within  the  Supply  Operations  Division  in  the  Marine  Corps.  The 
item  manager  completes  blocks  19  through  29  of  the  NIMSRs  and 
returns  the  completed  forms  to  the  submitting  activity.  The 
item  manager  then  forwards  a  copy  of  the  completed  form  to  the 
Technical  Operations  Division  for  appropriate  cataloging  action. 
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